The HUGEPD_*_SHIFT macros are always defined to be PGDIR_SHIFT and
PUD_SHIFT, and have to have those values to work properly. They once used
to have different values, but that was really only because they were used
to mean different things in different contexts.
6fa50483 "powerpc/mm/hugetlb:
On Fri, Jun 29, 2018 at 11:52 AM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> switches from an unchanging variable to a constant expression to eliminate
> the VLA generation.
>
> [1]
>
On Thu, 2018-07-05 at 08:47:00 UTC, Nicholas Piggin wrote:
> POWER9 DD1 was never a product. It is no longer supported by upstream
> firmware, and it is not effectively supported in Linux due to lack of
> testing.
>
> Signed-off-by: Nicholas Piggin
Applied to powerpc topic/ppc-kvm, thanks.
On Wed, 2018-07-04 at 06:13:44 UTC, Alexey Kardashevskiy wrote:
> This gets rid of a useless wrapper around
> pnv_pci_ioda2_table_free_pages().
>
> Reviewed-by: David Gibson
> Signed-off-by: Alexey Kardashevskiy
Series applied to powerpc topic/ppc-kvm, thanks.
On Thu, Jul 12, 2018 at 05:30:26PM +1000, Alexey Kardashevskiy wrote:
> This adds a debugfs entry with mm context id of a process which is using
> KVM. This id is an index in the process table so the userspace can dump
> that tree provided it is granted access to /dev/mem.
Is the main intention
Hi Diana,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.18-rc5 next-20180713]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On Fri, Jul 13, 2018 at 09:22:23AM -0500, John Allen wrote:
When a PRRN event is being handled and another PRRN event comes in, the
second event will block rtas polling waiting on the first to complete,
preventing any further rtas events from being handled. This can be
especially problematic in
From: Randy Dunlap
Date: Fri, 13 Jul 2018 21:25:19 -0700
> From: Randy Dunlap
>
> CC [M] drivers/net/ethernet/freescale/fman/fman.o
> In file included from ../drivers/net/ethernet/freescale/fman/fman.c:35:
> ../include/linux/fsl/guts.h: In function 'guts_set_dmacr':
>
On Mon, 2018-07-16 at 14:23 +0530, Abdul Haleem wrote:
> mpt3sas module unload triggered a warning at block/blk-core.c:781 on a
> powerpc bare-metal running mainline kernel
>
> WARN_ON_ONCE() was introduced with commit a063057 : block: Fix a race
> between request queue removal and the block
Greeting's
Today's next kernel panics while booting powerpc
Machine: Power 8 Bare-metal
kernel : 4.18.0-rc4-next-20180713
test: Boot
boot messages:
--
Reached target Timers.
Started System Logging Service.
Started Dump dmesg to /var/log/dmesg.
Started Login Service.
Started Resets
Greeting's
mpt3sas module unload triggered a warning at block/blk-core.c:781 on a
powerpc bare-metal running mainline kernel
WARN_ON_ONCE() was introduced with commit a063057 : block: Fix a race
between request queue removal and the block cgroup controller
Machine: Power8 Bare-metal
kernel :
On Mon 16-07-18 11:32:56, Mahesh J Salgaonkar wrote:
> One of the primary issues with Firmware Assisted Dump (fadump) on Power
> is that it needs a large amount of memory to be reserved. This reserved
> memory is used for saving the contents of old crashed kernel's memory before
> fadump capture
On 07/09/2018 02:19 PM, Marek Szyprowski wrote:
> The CMA memory allocator doesn't support standard gfp flags for memory
> allocation, so there is no point having it as a parameter for
> dma_alloc_from_contiguous() function. Replace it by a boolean no_warn
> argument, which covers all the
On 07/09/2018 02:19 PM, Marek Szyprowski wrote:
> cma_alloc() function doesn't really support gfp flags other than
> __GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.
>
> This will help to avoid giving false feeling that this function supports
> standard gfp flags and
From: Mahesh Salgaonkar
For fadump to work successfully there should not be any holes in reserved
memory ranges where kernel has asked firmware to move the content of old
kernel memory in event of crash. Now that fadump reserved memory is marked
as movable zone, this memory area is now not
From: Mahesh Salgaonkar
fadump fails to register when there are holes in reserved memory area.
This can happen if user has hot-removed a memory that falls in the fadump
reserved memory area. Throw a meaningful error message to the user in
such case.
Signed-off-by: Mahesh Salgaonkar
---
From: Mahesh Salgaonkar
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.
In some cases, fadump fails if the memory reserved is
From: Mahesh Salgaonkar
Add an interface to allow a custom reserved memory to be marked as
ZONE_MOVABLE. This will help some subsystem's to convert their reserved
memory region into ZONE_MOVABLE so that the memory can still be available
to user applications.
The approach is based on Joonsoo
One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. This reserved
memory is used for saving the contents of old crashed kernel's memory before
fadump capture kernel uses old kernel's memory area to boot. However, This
19 matches
Mail list logo
