Greeting's
Mainline kernel 5.16.0-rc5 panics when DLPAR ADD of vNIC device on my
Powerpc LPAR
Perform below dlpar commands in a loop from linux OS
drmgr -r -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
drmgr -a -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
after 7th iteration, the kernel panic
dxa command in XMON debugger iterates through all possible processors.
As a result, empty lines are printed even for processors which are not
online.
CPU 47:pp=00 CPPR=ff IPI=0x0040002f PQ=-- EQ idx=699 T=0
CPU 48:
CPU 49:
Restrict XIVE information(dxa) to be displayed for onlin
On 1/5/22 15:17, Sachin Sant wrote:
dxa command in XMON debugger iterates through all possible processors.
As a result, empty lines are printed even for processors which are not
online.
CPU 47:pp=00 CPPR=ff IPI=0x0040002f PQ=-- EQ idx=699 T=0
CPU 48:
CPU 49:
Restrict XIVE info
Happy New Year, Michael!
Do you consider taking that patch soon?
Thanks,
Laurent.
On 07/12/2021, 18:11:09, Laurent Dufour wrote:
> The LPAR name may be changed after the LPAR has been started in the HMC.
> In that case lparstat command is not reporting the updated value because it
> reads it fro
On Wed, 5 Jan 2022 13:56:53 +0530 Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel 5.16.0-rc5 panics when DLPAR ADD of vNIC device on my
> Powerpc LPAR
>
> Perform below dlpar commands in a loop from linux OS
>
> drmgr -r -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
> drmgr -a -c slot -s U9
There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the ibmveth sysfs code to use default_groups
field which has been the preferred way since aa30f47cf666 ("kobject: Add
support for default attribute groups
On 1/5/22 10:41 AM, Greg Kroah-Hartman wrote:
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the ibmveth sysfs code to use default_groups
> field which has been the preferred way since aa30f47cf66
From: Zi Yan
alloc_contig_range() worked at MAX_ORDER-1 granularity to avoid merging
pageblocks with different migratetypes. It might unnecessarily convert
extra pageblocks at the beginning and at the end of the range. Change
alloc_contig_range() to work at pageblock granularity.
It is done by r
From: Zi Yan
Hi all,
This patchset tries to remove the MAX_ORDER - 1 alignment requirement for CMA
and alloc_contig_range(). It prepares for my upcoming changes to make MAX_ORDER
adjustable at boot time[1]. It is on top of mmotm-2021-12-29-20-07.
The MAX_ORDER - 1 alignment requirement comes fr
From: Zi Yan
alloc_migration_target() is used by alloc_contig_range() and non-LRU
movable compound pages can be migrated. Current code does not allocate the
right page size for such pages. Check THP precisely using
is_transparent_huge() and add allocation support for non-LRU compound
pages.
Sign
From: Zi Yan
This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
It prepares for the upcoming removal of the MAX_ORDER-1 alignment
requirement for CMA and alloc_contig_range().
MIGRARTE_HIGHATOMIC should not merge with other migratetypes like
MIGRATE_ISOLATE and MIGRARTE_CMA[1
From: Zi Yan
In isolate_migratepages_block(), a !PageLRU tail page can be encountered
when the page is larger than a pageblock. Use compound head page for the
checks inside and skip the entire compound page when isolation succeeds.
Signed-off-by: Zi Yan
---
mm/compaction.c | 10 +++---
1 f
From: Zi Yan
Now alloc_contig_range() works at pageblock granularity. Change CMA
allocation, which uses alloc_contig_range(), to use pageblock_order
alignment.
Signed-off-by: Zi Yan
---
include/linux/mmzone.h | 5 +
kernel/dma/contiguous.c | 2 +-
mm/cma.c| 6 ++
mm/pa
From: Zi Yan
CMA only requires pageblock alignment now. Change CMA alignment in
fadump too.
Signed-off-by: Zi Yan
---
arch/powerpc/include/asm/fadump-internal.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump-internal.h
b/arch/powerpc/inc
From: Zi Yan
alloc_contig_range() now only needs to be aligned to pageblock_order,
drop virtio_mem size requirement that it needs to be the max of
pageblock_order and MAX_ORDER.
Signed-off-by: Zi Yan
---
drivers/virtio/virtio_mem.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
From: Zi Yan
Enable set_migratetype_isolate() to check specified sub-range for
unmovable pages during isolation. Page isolation is done
at max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) granularity, but not all
pages within that granularity are intended to be isolated. For example,
alloc_contig_rang
Laurent Dufour writes:
> On 07/12/2021, 18:11:09, Laurent Dufour wrote:
>> The LPAR name may be changed after the LPAR has been started in the HMC.
>> In that case lparstat command is not reporting the updated value because it
>> reads it from the device tree which is read at boot time.
>>
>> How
On 1/5/22 3:19 PM, Nathan Lynch wrote:
> Laurent Dufour writes:
>> On 07/12/2021, 18:11:09, Laurent Dufour wrote:
>>> The LPAR name may be changed after the LPAR has been started in the HMC.
>>> In that case lparstat command is not reporting the updated value because it
>>> reads it from the devic
Tyrel Datwyler writes:
> On 1/5/22 3:19 PM, Nathan Lynch wrote:
>> Laurent Dufour writes:
>>> On 07/12/2021, 18:11:09, Laurent Dufour wrote:
The LPAR name may be changed after the LPAR has been started in the HMC.
In that case lparstat command is not reporting the updated value because
Kip Warner writes:
>Dec 25 06:52:52 romulus-server kernel: [28835.277591] BUG: Unable to
> handle kernel data access on write at 0x132b47d38499fd58
>Dec 25 06:52:52 romulus-server kernel: [28835.277624] Faulting instruction
> address: 0xc04d0434
>Dec 25 06:52:52 romulus-serve
On 1/5/22 5:36 PM, Nathan Lynch wrote:
> Tyrel Datwyler writes:
>> On 1/5/22 3:19 PM, Nathan Lynch wrote:
>>>
>>
>> Is there benefit of adding a partition_name field/value pair to lparcfg? The
>> lparstat utility can just as easily make the get_sysparm call via librtas.
>> Further, rtas_filters al
Nathan Lynch writes:
> Kip Warner writes:
>>Dec 25 06:52:52 romulus-server kernel: [28835.277591] BUG: Unable to
>> handle kernel data access on write at 0x132b47d38499fd58
>>Dec 25 06:52:52 romulus-server kernel: [28835.277624] Faulting
>> instruction address: 0xc04d0434
>>
Jakub Kicinski writes:
> On Wed, 5 Jan 2022 13:56:53 +0530 Abdul Haleem wrote:
>> Greeting's
>>
>> Mainline kernel 5.16.0-rc5 panics when DLPAR ADD of vNIC device on my
>> Powerpc LPAR
>>
>> Perform below dlpar commands in a loop from linux OS
>>
>> drmgr -r -c slot -s U9080.HEX.134C488-V1-C3
> On 05-Jan-2022, at 8:09 PM, Cédric Le Goater wrote:
>
> On 1/5/22 15:17, Sachin Sant wrote:
>> dxa command in XMON debugger iterates through all possible processors.
>> As a result, empty lines are printed even for processors which are not
>> online.
>> CPU 47:pp=00 CPPR=ff IPI=0x0040002f PQ=
24 matches
Mail list logo
