| Message ID | 20220302044406.63401-12-ash@heyquark.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | powerpc: Nintendo Wii U support | expand |
On Wednesday 02 March 2022 15:44:05 Ash Logan wrote: > pgtable_32.c:mapin_ram loops over each valid memory range, which means > non-contiguous memory just works. Hello! Does it mean that non-contiguous memory works for any 32-bit powerpc platform, and not only for wiiu? If yes, should not be non-contiguous memory support enabled for all 32-bit ppc boards then? > Signed-off-by: Ash Logan <ash@heyquark.com> > --- > arch/powerpc/mm/init_32.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c > index 3d690be48e84..59a84629d9a0 100644 > --- a/arch/powerpc/mm/init_32.c > +++ b/arch/powerpc/mm/init_32.c > @@ -125,10 +125,10 @@ void __init MMU_init(void) > * lowmem_end_addr is initialized below. > */ > if (memblock.memory.cnt > 1) { > -#ifndef CONFIG_WII > +#if !defined(CONFIG_WII) && !defined(CONFIG_WIIU) > memblock_enforce_memory_limit(memblock.memory.regions[0].size); > pr_warn("Only using first contiguous memory region\n"); > -#else > +#elif defined(CONFIG_WII) > wii_memory_fixups(); > #endif > } > -- > 2.35.1 >
On 14/5/22 08:43, Pali Rohár wrote: > On Wednesday 02 March 2022 15:44:05 Ash Logan wrote: >> pgtable_32.c:mapin_ram loops over each valid memory range, which means >> non-contiguous memory just works. > > Hello! Does it mean that non-contiguous memory works for any 32-bit > powerpc platform, and not only for wiiu? If yes, should not be > non-contiguous memory support enabled for all 32-bit ppc boards then? Hi! Sorry for my delayed response. As best I can tell, it does indeed Just Work, but I have only been able to test on wiiu which is missing a lot of features other boards have (like PCI) - so it's possible there's still an assumption elsewhere in the kernel that I haven't hit. As best I can tell, the Wii and Wii U are the only 32-bit powerpc boards out there where it's even possible to have non-contiguous memory. >> Signed-off-by: Ash Logan <ash@heyquark.com> >> --- >> arch/powerpc/mm/init_32.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c >> index 3d690be48e84..59a84629d9a0 100644 >> --- a/arch/powerpc/mm/init_32.c >> +++ b/arch/powerpc/mm/init_32.c >> @@ -125,10 +125,10 @@ void __init MMU_init(void) >> * lowmem_end_addr is initialized below. >> */ >> if (memblock.memory.cnt > 1) { >> -#ifndef CONFIG_WII >> +#if !defined(CONFIG_WII) && !defined(CONFIG_WIIU) >> memblock_enforce_memory_limit(memblock.memory.regions[0].size); >> pr_warn("Only using first contiguous memory region\n"); >> -#else >> +#elif defined(CONFIG_WII) >> wii_memory_fixups(); >> #endif >> } >> -- >> 2.35.1 >>
On Friday 20 May 2022 13:41:04 Ash Logan wrote: > On 14/5/22 08:43, Pali Rohár wrote: > > On Wednesday 02 March 2022 15:44:05 Ash Logan wrote: > >> pgtable_32.c:mapin_ram loops over each valid memory range, which means > >> non-contiguous memory just works. > > > > Hello! Does it mean that non-contiguous memory works for any 32-bit > > powerpc platform, and not only for wiiu? If yes, should not be > > non-contiguous memory support enabled for all 32-bit ppc boards then? > > Hi! Sorry for my delayed response. As best I can tell, it does indeed > Just Work, but I have only been able to test on wiiu which is missing a > lot of features other boards have (like PCI) - so it's possible there's > still an assumption elsewhere in the kernel that I haven't hit. > > As best I can tell, the Wii and Wii U are the only 32-bit powerpc boards > out there where it's even possible to have non-contiguous memory. What is the reason that those two boards are the **only**? Is there some specific requirement from bootloader or hardware to "enable" non-contiguous memory support? I'm interested in enabling non-contiguous memory support for P2020-based board as it has gaps in its 32-bit memory layout and which could be used for RAM mapping when 4GB DDR3 module is plugged in (default is 2GB). > >> Signed-off-by: Ash Logan <ash@heyquark.com> > >> --- > >> arch/powerpc/mm/init_32.c | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c > >> index 3d690be48e84..59a84629d9a0 100644 > >> --- a/arch/powerpc/mm/init_32.c > >> +++ b/arch/powerpc/mm/init_32.c > >> @@ -125,10 +125,10 @@ void __init MMU_init(void) > >> * lowmem_end_addr is initialized below. > >> */ > >> if (memblock.memory.cnt > 1) { > >> -#ifndef CONFIG_WII > >> +#if !defined(CONFIG_WII) && !defined(CONFIG_WIIU) > >> memblock_enforce_memory_limit(memblock.memory.regions[0].size); > >> pr_warn("Only using first contiguous memory region\n"); > >> -#else > >> +#elif defined(CONFIG_WII) > >> wii_memory_fixups(); > >> #endif > >> } > >> -- > >> 2.35.1 > >>
On 20/5/22 18:04, Pali Rohár wrote: > On Friday 20 May 2022 13:41:04 Ash Logan wrote: >> On 14/5/22 08:43, Pali Rohár wrote: >>> On Wednesday 02 March 2022 15:44:05 Ash Logan wrote: >>>> pgtable_32.c:mapin_ram loops over each valid memory range, which means >>>> non-contiguous memory just works. >>> >>> Hello! Does it mean that non-contiguous memory works for any 32-bit >>> powerpc platform, and not only for wiiu? If yes, should not be >>> non-contiguous memory support enabled for all 32-bit ppc boards then? >> >> Hi! Sorry for my delayed response. As best I can tell, it does indeed >> Just Work, but I have only been able to test on wiiu which is missing a >> lot of features other boards have (like PCI) - so it's possible there's >> still an assumption elsewhere in the kernel that I haven't hit. >> >> As best I can tell, the Wii and Wii U are the only 32-bit powerpc boards >> out there where it's even possible to have non-contiguous memory. > > What is the reason that those two boards are the **only**? Is there some > specific requirement from bootloader or hardware to "enable" > non-contiguous memory support? Not that I know of, I was just saying that I was only aware of those two boards where the memory map isn't contiguous, and that is the only place where it has been tested. Evidently you know of another board! > I'm interested in enabling non-contiguous memory support for P2020-based > board as it has gaps in its 32-bit memory layout and which could be used > for RAM mapping when 4GB DDR3 module is plugged in (default is 2GB). If it's like the Wii or Wii U (some memory at 0, a gap for MMIO or whatever, then more memory at a higher address) then you should try a patch along these lines, because barring the unknowns I mentioned before it should work. At least as far as I'm aware ;) >>>> Signed-off-by: Ash Logan <ash@heyquark.com> >>>> --- >>>> arch/powerpc/mm/init_32.c | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c >>>> index 3d690be48e84..59a84629d9a0 100644 >>>> --- a/arch/powerpc/mm/init_32.c >>>> +++ b/arch/powerpc/mm/init_32.c >>>> @@ -125,10 +125,10 @@ void __init MMU_init(void) >>>> * lowmem_end_addr is initialized below. >>>> */ >>>> if (memblock.memory.cnt > 1) { >>>> -#ifndef CONFIG_WII >>>> +#if !defined(CONFIG_WII) && !defined(CONFIG_WIIU) >>>> memblock_enforce_memory_limit(memblock.memory.regions[0].size); >>>> pr_warn("Only using first contiguous memory region\n"); >>>> -#else >>>> +#elif defined(CONFIG_WII) >>>> wii_memory_fixups(); >>>> #endif >>>> } >>>> -- >>>> 2.35.1 >>>>
+ linux-mm Do you know what are requirements for kernel to support non-contiguous memory support and what is needed to enable it for 32-bit powerpc? Currently powerpc arch code does not support "memblock.memory.cnt > 1" except for WII which seems like a hack... See below. On Friday 20 May 2022 20:44:04 Ash Logan wrote: > On 20/5/22 18:04, Pali Rohár wrote: > > On Friday 20 May 2022 13:41:04 Ash Logan wrote: > >> On 14/5/22 08:43, Pali Rohár wrote: > >>> On Wednesday 02 March 2022 15:44:05 Ash Logan wrote: > >>>> pgtable_32.c:mapin_ram loops over each valid memory range, which means > >>>> non-contiguous memory just works. > >>> > >>> Hello! Does it mean that non-contiguous memory works for any 32-bit > >>> powerpc platform, and not only for wiiu? If yes, should not be > >>> non-contiguous memory support enabled for all 32-bit ppc boards then? > >> > >> Hi! Sorry for my delayed response. As best I can tell, it does indeed > >> Just Work, but I have only been able to test on wiiu which is missing a > >> lot of features other boards have (like PCI) - so it's possible there's > >> still an assumption elsewhere in the kernel that I haven't hit. > >> > >> As best I can tell, the Wii and Wii U are the only 32-bit powerpc boards > >> out there where it's even possible to have non-contiguous memory. > > > > What is the reason that those two boards are the **only**? Is there some > > specific requirement from bootloader or hardware to "enable" > > non-contiguous memory support? > > Not that I know of, I was just saying that I was only aware of those two > boards where the memory map isn't contiguous, and that is the only place > where it has been tested. Evidently you know of another board! > > > I'm interested in enabling non-contiguous memory support for P2020-based > > board as it has gaps in its 32-bit memory layout and which could be used > > for RAM mapping when 4GB DDR3 module is plugged in (default is 2GB). > > If it's like the Wii or Wii U (some memory at 0, a gap for MMIO or > whatever, then more memory at a higher address) then you should try a > patch along these lines, because barring the unknowns I mentioned before > it should work. At least as far as I'm aware ;) > > >>>> Signed-off-by: Ash Logan <ash@heyquark.com> > >>>> --- > >>>> arch/powerpc/mm/init_32.c | 4 ++-- > >>>> 1 file changed, 2 insertions(+), 2 deletions(-) > >>>> > >>>> diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c > >>>> index 3d690be48e84..59a84629d9a0 100644 > >>>> --- a/arch/powerpc/mm/init_32.c > >>>> +++ b/arch/powerpc/mm/init_32.c > >>>> @@ -125,10 +125,10 @@ void __init MMU_init(void) > >>>> * lowmem_end_addr is initialized below. > >>>> */ > >>>> if (memblock.memory.cnt > 1) { > >>>> -#ifndef CONFIG_WII > >>>> +#if !defined(CONFIG_WII) && !defined(CONFIG_WIIU) > >>>> memblock_enforce_memory_limit(memblock.memory.regions[0].size); > >>>> pr_warn("Only using first contiguous memory region\n"); > >>>> -#else > >>>> +#elif defined(CONFIG_WII) > >>>> wii_memory_fixups(); > >>>> #endif > >>>> } > >>>> -- > >>>> 2.35.1 > >>>>
On Friday 20 May 2022 14:30:02 Pali Rohár wrote: > + linux-mm > > Do you know what are requirements for kernel to support non-contiguous > memory support and what is needed to enable it for 32-bit powerpc? Any hints? > Currently powerpc arch code does not support "memblock.memory.cnt > 1" > except for WII which seems like a hack... See below. > > On Friday 20 May 2022 20:44:04 Ash Logan wrote: > > On 20/5/22 18:04, Pali Rohár wrote: > > > On Friday 20 May 2022 13:41:04 Ash Logan wrote: > > >> On 14/5/22 08:43, Pali Rohár wrote: > > >>> On Wednesday 02 March 2022 15:44:05 Ash Logan wrote: > > >>>> pgtable_32.c:mapin_ram loops over each valid memory range, which means > > >>>> non-contiguous memory just works. > > >>> > > >>> Hello! Does it mean that non-contiguous memory works for any 32-bit > > >>> powerpc platform, and not only for wiiu? If yes, should not be > > >>> non-contiguous memory support enabled for all 32-bit ppc boards then? > > >> > > >> Hi! Sorry for my delayed response. As best I can tell, it does indeed > > >> Just Work, but I have only been able to test on wiiu which is missing a > > >> lot of features other boards have (like PCI) - so it's possible there's > > >> still an assumption elsewhere in the kernel that I haven't hit. > > >> > > >> As best I can tell, the Wii and Wii U are the only 32-bit powerpc boards > > >> out there where it's even possible to have non-contiguous memory. > > > > > > What is the reason that those two boards are the **only**? Is there some > > > specific requirement from bootloader or hardware to "enable" > > > non-contiguous memory support? > > > > Not that I know of, I was just saying that I was only aware of those two > > boards where the memory map isn't contiguous, and that is the only place > > where it has been tested. Evidently you know of another board! > > > > > I'm interested in enabling non-contiguous memory support for P2020-based > > > board as it has gaps in its 32-bit memory layout and which could be used > > > for RAM mapping when 4GB DDR3 module is plugged in (default is 2GB). > > > > If it's like the Wii or Wii U (some memory at 0, a gap for MMIO or > > whatever, then more memory at a higher address) then you should try a > > patch along these lines, because barring the unknowns I mentioned before > > it should work. At least as far as I'm aware ;) > > > > >>>> Signed-off-by: Ash Logan <ash@heyquark.com> > > >>>> --- > > >>>> arch/powerpc/mm/init_32.c | 4 ++-- > > >>>> 1 file changed, 2 insertions(+), 2 deletions(-) > > >>>> > > >>>> diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c > > >>>> index 3d690be48e84..59a84629d9a0 100644 > > >>>> --- a/arch/powerpc/mm/init_32.c > > >>>> +++ b/arch/powerpc/mm/init_32.c > > >>>> @@ -125,10 +125,10 @@ void __init MMU_init(void) > > >>>> * lowmem_end_addr is initialized below. > > >>>> */ > > >>>> if (memblock.memory.cnt > 1) { > > >>>> -#ifndef CONFIG_WII > > >>>> +#if !defined(CONFIG_WII) && !defined(CONFIG_WIIU) > > >>>> memblock_enforce_memory_limit(memblock.memory.regions[0].size); > > >>>> pr_warn("Only using first contiguous memory region\n"); > > >>>> -#else > > >>>> +#elif defined(CONFIG_WII) > > >>>> wii_memory_fixups(); > > >>>> #endif > > >>>> } > > >>>> -- > > >>>> 2.35.1 > > >>>>
On Friday 10 June 2022 00:24:20 Pali Rohár wrote: > On Friday 20 May 2022 14:30:02 Pali Rohár wrote: > > + linux-mm > > > > Do you know what are requirements for kernel to support non-contiguous > > memory support and what is needed to enable it for 32-bit powerpc? > > Any hints? PING? > > Currently powerpc arch code does not support "memblock.memory.cnt > 1" > > except for WII which seems like a hack... See below. > > > > On Friday 20 May 2022 20:44:04 Ash Logan wrote: > > > On 20/5/22 18:04, Pali Rohár wrote: > > > > On Friday 20 May 2022 13:41:04 Ash Logan wrote: > > > >> On 14/5/22 08:43, Pali Rohár wrote: > > > >>> On Wednesday 02 March 2022 15:44:05 Ash Logan wrote: > > > >>>> pgtable_32.c:mapin_ram loops over each valid memory range, which means > > > >>>> non-contiguous memory just works. > > > >>> > > > >>> Hello! Does it mean that non-contiguous memory works for any 32-bit > > > >>> powerpc platform, and not only for wiiu? If yes, should not be > > > >>> non-contiguous memory support enabled for all 32-bit ppc boards then? > > > >> > > > >> Hi! Sorry for my delayed response. As best I can tell, it does indeed > > > >> Just Work, but I have only been able to test on wiiu which is missing a > > > >> lot of features other boards have (like PCI) - so it's possible there's > > > >> still an assumption elsewhere in the kernel that I haven't hit. > > > >> > > > >> As best I can tell, the Wii and Wii U are the only 32-bit powerpc boards > > > >> out there where it's even possible to have non-contiguous memory. > > > > > > > > What is the reason that those two boards are the **only**? Is there some > > > > specific requirement from bootloader or hardware to "enable" > > > > non-contiguous memory support? > > > > > > Not that I know of, I was just saying that I was only aware of those two > > > boards where the memory map isn't contiguous, and that is the only place > > > where it has been tested. Evidently you know of another board! > > > > > > > I'm interested in enabling non-contiguous memory support for P2020-based > > > > board as it has gaps in its 32-bit memory layout and which could be used > > > > for RAM mapping when 4GB DDR3 module is plugged in (default is 2GB). > > > > > > If it's like the Wii or Wii U (some memory at 0, a gap for MMIO or > > > whatever, then more memory at a higher address) then you should try a > > > patch along these lines, because barring the unknowns I mentioned before > > > it should work. At least as far as I'm aware ;) > > > > > > >>>> Signed-off-by: Ash Logan <ash@heyquark.com> > > > >>>> --- > > > >>>> arch/powerpc/mm/init_32.c | 4 ++-- > > > >>>> 1 file changed, 2 insertions(+), 2 deletions(-) > > > >>>> > > > >>>> diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c > > > >>>> index 3d690be48e84..59a84629d9a0 100644 > > > >>>> --- a/arch/powerpc/mm/init_32.c > > > >>>> +++ b/arch/powerpc/mm/init_32.c > > > >>>> @@ -125,10 +125,10 @@ void __init MMU_init(void) > > > >>>> * lowmem_end_addr is initialized below. > > > >>>> */ > > > >>>> if (memblock.memory.cnt > 1) { > > > >>>> -#ifndef CONFIG_WII > > > >>>> +#if !defined(CONFIG_WII) && !defined(CONFIG_WIIU) > > > >>>> memblock_enforce_memory_limit(memblock.memory.regions[0].size); > > > >>>> pr_warn("Only using first contiguous memory region\n"); > > > >>>> -#else > > > >>>> +#elif defined(CONFIG_WII) > > > >>>> wii_memory_fixups(); > > > >>>> #endif > > > >>>> } > > > >>>> -- > > > >>>> 2.35.1 > > > >>>>
Le 08/08/2022 à 20:40, Pali Rohár a écrit : > On Friday 10 June 2022 00:24:20 Pali Rohár wrote: >> On Friday 20 May 2022 14:30:02 Pali Rohár wrote: >>> + linux-mm >>> >>> Do you know what are requirements for kernel to support non-contiguous >>> memory support and what is needed to enable it for 32-bit powerpc? >> >> Any hints? > > PING? > The tree following patches landed in powerpc/next branch, so they should soon be visible in linux-next too: fc06755e2562 ("powerpc/32: Drop a stale comment about reservation of gigantic pages") b0e0d68b1c52 ("powerpc/32: Allow fragmented physical memory") 0115953dcebe ("powerpc/32: Remove wii_memory_fixups()")
On Thursday 08 September 2022 15:25:14 Christophe Leroy wrote: > Le 08/08/2022 à 20:40, Pali Rohár a écrit : > > On Friday 10 June 2022 00:24:20 Pali Rohár wrote: > >> On Friday 20 May 2022 14:30:02 Pali Rohár wrote: > >>> + linux-mm > >>> > >>> Do you know what are requirements for kernel to support non-contiguous > >>> memory support and what is needed to enable it for 32-bit powerpc? > >> > >> Any hints? > > > > PING? > > > > The tree following patches landed in powerpc/next branch, so they should > soon be visible in linux-next too: > > fc06755e2562 ("powerpc/32: Drop a stale comment about reservation of > gigantic pages") > b0e0d68b1c52 ("powerpc/32: Allow fragmented physical memory") > 0115953dcebe ("powerpc/32: Remove wii_memory_fixups()") Ou, nice! I will try to test it if it allows me to access more than 2GB of RAM from 4GB DDR3 module with 32-bit addressing mode on P2020 CPU.
On Thursday 08 September 2022 17:35:11 Pali Rohár wrote: > On Thursday 08 September 2022 15:25:14 Christophe Leroy wrote: > > Le 08/08/2022 à 20:40, Pali Rohár a écrit : > > > On Friday 10 June 2022 00:24:20 Pali Rohár wrote: > > >> On Friday 20 May 2022 14:30:02 Pali Rohár wrote: > > >>> + linux-mm > > >>> > > >>> Do you know what are requirements for kernel to support non-contiguous > > >>> memory support and what is needed to enable it for 32-bit powerpc? > > >> > > >> Any hints? > > > > > > PING? > > > > > > > The tree following patches landed in powerpc/next branch, so they should > > soon be visible in linux-next too: > > > > fc06755e2562 ("powerpc/32: Drop a stale comment about reservation of > > gigantic pages") > > b0e0d68b1c52 ("powerpc/32: Allow fragmented physical memory") > > 0115953dcebe ("powerpc/32: Remove wii_memory_fixups()") > > Ou, nice! I will try to test it if it allows me to access more than 2GB > of RAM from 4GB DDR3 module with 32-bit addressing mode on P2020 CPU. Hello! Ok, I have tried it from powerpc/next branch, but seems it does not work. I'm getting just early kernel crash. [ 0.000000] CPU maps initialized for 1 thread per core [ 0.000000] (thread shift is 0) [ 0.000000] ----------------------------------------------------- [ 0.000000] phys_mem_size = 0xbe500000 [ 0.000000] dcache_bsize = 0x20 [ 0.000000] icache_bsize = 0x20 [ 0.000000] cpu_features = 0x0000000010010108 [ 0.000000] possible = 0x0000000010010108 [ 0.000000] always = 0x0000000010010108 [ 0.000000] cpu_user_features = 0x84e08000 0x08000000 [ 0.000000] mmu_features = 0x00020010 [ 0.000000] ----------------------------------------------------- mpc85xx_rdb_setup_arch() [ 0.000000] ioremap() called early from of_iomap+0x48/0x80. Use early_ioremap() instead [ 0.000000] MPC85xx RDB board from Freescale Semiconductor [ 0.000000] barrier-nospec: using isync; sync as speculation barrier [ 0.000000] barrier-nospec: patched 182 locations [ 0.000000] Top of RAM: 0xff700000, Total RAM: 0xbe500000 [ 0.000000] Memory hole size: 1042MB [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] HighMem [mem 0x0000000030000000-0x00000000ff6fffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x000000007fffffff] [ 0.000000] node 0: [mem 0x00000000c0200000-0x00000000eeffffff] [ 0.000000] node 0: [mem 0x00000000f0000000-0x00000000ff6fffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000ff6fffff] [ 0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts [ 0.000000] percpu: Embedded 11 pages/cpu s14196 r8192 d22668 u45056 [ 0.000000] pcpu-alloc: s14196 r8192 d22668 u45056 alloc=11*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 777792 [ 0.000000] Kernel command line: root=ubi0:rootfs rootfstype=ubifs ubi.mtd=rootfs,2048 rootflags=chk_data_crc rw console=ttyS0,115200 [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Kernel attempted to read user page (7df58) - exploit attempt? (uid: 0) [ 0.000000] BUG: Unable to handle kernel data access on read at 0x0007df58 [ 0.000000] Faulting instruction address: 0xc01c8348 [ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1] [ 0.000000] BE PAGE_SIZE=4K SMP NR_CPUS=2 P2020RDB-PC [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc2-0caacb197b677410bdac81bc34f05235+ #121 [ 0.000000] NIP: c01c8348 LR: c01cb2bc CTR: 0000000a [ 0.000000] REGS: c10d7e20 TRAP: 0300 Not tainted (6.0.0-rc2-0caacb197b677410bdac81bc34f05235+) [ 0.000000] MSR: 00021000 <CE,ME> CR: 48044224 XER: 00000000 [ 0.000000] DEAR: 0007df58 ESR: 00000000 [ 0.000000] GPR00: c01cb294 c10d7f10 c1045340 00000001 00000004 c112bcc0 00000015 eedf1000 [ 0.000000] GPR08: 00000003 0007df58 00000000 f0000000 28044228 00000200 00000000 00000000 [ 0.000000] GPR16: 00000000 00000000 00000000 0275cb7a c0000000 00000001 0000075f 00000000 [ 0.000000] GPR24: c1031004 00000000 00000000 00000001 c10f0000 eedf1000 00080000 00080000 [ 0.000000] NIP [c01c8348] free_unref_page_prepare.part.93+0x48/0x60 [ 0.000000] LR [c01cb2bc] free_unref_page+0x84/0x4b8 [ 0.000000] Call Trace: [ 0.000000] [c10d7f10] [eedf1000] 0xeedf1000 (unreliable) [ 0.000000] [c10d7f20] [c01cb294] free_unref_page+0x5c/0x4b8 [ 0.000000] [c10d7f70] [c1007644] mem_init+0xd0/0x194 [ 0.000000] [c10d7fa0] [c1000e4c] start_kernel+0x4c0/0x6d0 [ 0.000000] [c10d7ff0] [c00003e0] set_ivor+0x13c/0x178 [ 0.000000] Instruction dump: [ 0.000000] 552817be 5509103a 7d294214 55293830 7d4a4a14 812a003c 814a0038 5529002a [ 0.000000] 7c892050 5484c23a 5489eafa 548406fe <7d2a482e> 7d242430 5484077e 90870010 [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] [ 0.000000] Kernel panic - not syncing: Fatal exception [ 0.000000] Rebooting in 1 seconds.. [ 0.000000] System Halted, OK to turn off power 4GB DDR3 SODIMM module is set via Freescale LBC to the whole 4 GB address range. And on ranges: 0x0000_0000 - 0x7fff_ffff 0xc020_0000 - 0xeeff_ffff 0xf000_0000 - 0xff6f_ffff there is no peripheral device, they are free for DRAM. Between these physical ranges are mapped peripheral devices (PCIe and NOR). Any idea if I'm doing something wrong or there can be a bug in memory code? Quite suspicious is that "Initmem setup node 0" prints one range where are also peripherals, not just DRAM. Crash is on address 0xc01c8348 which belongs to PCIe.
+ Adding Mike who might help if the problem is around memblock. Le 08/09/2022 à 22:17, Pali Rohár a écrit : > On Thursday 08 September 2022 17:35:11 Pali Rohár wrote: >> On Thursday 08 September 2022 15:25:14 Christophe Leroy wrote: >>> Le 08/08/2022 à 20:40, Pali Rohár a écrit : >>>> On Friday 10 June 2022 00:24:20 Pali Rohár wrote: >>>>> On Friday 20 May 2022 14:30:02 Pali Rohár wrote: >>>>>> + linux-mm >>>>>> >>>>>> Do you know what are requirements for kernel to support non-contiguous >>>>>> memory support and what is needed to enable it for 32-bit powerpc? >>>>> >>>>> Any hints? >>>> >>>> PING? >>>> >>> >>> The tree following patches landed in powerpc/next branch, so they should >>> soon be visible in linux-next too: >>> >>> fc06755e2562 ("powerpc/32: Drop a stale comment about reservation of >>> gigantic pages") >>> b0e0d68b1c52 ("powerpc/32: Allow fragmented physical memory") >>> 0115953dcebe ("powerpc/32: Remove wii_memory_fixups()") >> >> Ou, nice! I will try to test it if it allows me to access more than 2GB >> of RAM from 4GB DDR3 module with 32-bit addressing mode on P2020 CPU. > > Hello! Ok, I have tried it from powerpc/next branch, but seems it does > not work. I'm getting just early kernel crash. > > [ 0.000000] CPU maps initialized for 1 thread per core > [ 0.000000] (thread shift is 0) > [ 0.000000] ----------------------------------------------------- > [ 0.000000] phys_mem_size = 0xbe500000 > [ 0.000000] dcache_bsize = 0x20 > [ 0.000000] icache_bsize = 0x20 > [ 0.000000] cpu_features = 0x0000000010010108 > [ 0.000000] possible = 0x0000000010010108 > [ 0.000000] always = 0x0000000010010108 > [ 0.000000] cpu_user_features = 0x84e08000 0x08000000 > [ 0.000000] mmu_features = 0x00020010 > [ 0.000000] ----------------------------------------------------- > mpc85xx_rdb_setup_arch() > [ 0.000000] ioremap() called early from of_iomap+0x48/0x80. Use early_ioremap() instead > [ 0.000000] MPC85xx RDB board from Freescale Semiconductor > [ 0.000000] barrier-nospec: using isync; sync as speculation barrier > [ 0.000000] barrier-nospec: patched 182 locations > [ 0.000000] Top of RAM: 0xff700000, Total RAM: 0xbe500000 > [ 0.000000] Memory hole size: 1042MB > [ 0.000000] Zone ranges: > [ 0.000000] Normal [mem 0x0000000000000000-0x000000002fffffff] > [ 0.000000] HighMem [mem 0x0000000030000000-0x00000000ff6fffff] > [ 0.000000] Movable zone start for each node > [ 0.000000] Early memory node ranges > [ 0.000000] node 0: [mem 0x0000000000000000-0x000000007fffffff] > [ 0.000000] node 0: [mem 0x00000000c0200000-0x00000000eeffffff] > [ 0.000000] node 0: [mem 0x00000000f0000000-0x00000000ff6fffff] > [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000ff6fffff] > [ 0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts > [ 0.000000] percpu: Embedded 11 pages/cpu s14196 r8192 d22668 u45056 > [ 0.000000] pcpu-alloc: s14196 r8192 d22668 u45056 alloc=11*4096 > [ 0.000000] pcpu-alloc: [0] 0 [0] 1 > [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 777792 > [ 0.000000] Kernel command line: root=ubi0:rootfs rootfstype=ubifs ubi.mtd=rootfs,2048 rootflags=chk_data_crc rw console=ttyS0,115200 > [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) > [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) > [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off > [ 0.000000] Kernel attempted to read user page (7df58) - exploit attempt? (uid: 0) > [ 0.000000] BUG: Unable to handle kernel data access on read at 0x0007df58 > [ 0.000000] Faulting instruction address: 0xc01c8348 > [ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1] > [ 0.000000] BE PAGE_SIZE=4K SMP NR_CPUS=2 P2020RDB-PC > [ 0.000000] Modules linked in: > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc2-0caacb197b677410bdac81bc34f05235+ #121 > [ 0.000000] NIP: c01c8348 LR: c01cb2bc CTR: 0000000a > [ 0.000000] REGS: c10d7e20 TRAP: 0300 Not tainted (6.0.0-rc2-0caacb197b677410bdac81bc34f05235+) > [ 0.000000] MSR: 00021000 <CE,ME> CR: 48044224 XER: 00000000 > [ 0.000000] DEAR: 0007df58 ESR: 00000000 > [ 0.000000] GPR00: c01cb294 c10d7f10 c1045340 00000001 00000004 c112bcc0 00000015 eedf1000 > [ 0.000000] GPR08: 00000003 0007df58 00000000 f0000000 28044228 00000200 00000000 00000000 > [ 0.000000] GPR16: 00000000 00000000 00000000 0275cb7a c0000000 00000001 0000075f 00000000 > [ 0.000000] GPR24: c1031004 00000000 00000000 00000001 c10f0000 eedf1000 00080000 00080000 > [ 0.000000] NIP [c01c8348] free_unref_page_prepare.part.93+0x48/0x60 > [ 0.000000] LR [c01cb2bc] free_unref_page+0x84/0x4b8 > [ 0.000000] Call Trace: > [ 0.000000] [c10d7f10] [eedf1000] 0xeedf1000 (unreliable) > [ 0.000000] [c10d7f20] [c01cb294] free_unref_page+0x5c/0x4b8 > [ 0.000000] [c10d7f70] [c1007644] mem_init+0xd0/0x194 > [ 0.000000] [c10d7fa0] [c1000e4c] start_kernel+0x4c0/0x6d0 > [ 0.000000] [c10d7ff0] [c00003e0] set_ivor+0x13c/0x178 > [ 0.000000] Instruction dump: > [ 0.000000] 552817be 5509103a 7d294214 55293830 7d4a4a14 812a003c 814a0038 5529002a > [ 0.000000] 7c892050 5484c23a 5489eafa 548406fe <7d2a482e> 7d242430 5484077e 90870010 > [ 0.000000] ---[ end trace 0000000000000000 ]--- > [ 0.000000] > [ 0.000000] Kernel panic - not syncing: Fatal exception > [ 0.000000] Rebooting in 1 seconds.. > [ 0.000000] System Halted, OK to turn off power > > 4GB DDR3 SODIMM module is set via Freescale LBC to the whole 4 GB > address range. And on ranges: > 0x0000_0000 - 0x7fff_ffff > 0xc020_0000 - 0xeeff_ffff > 0xf000_0000 - 0xff6f_ffff > there is no peripheral device, they are free for DRAM. Between these > physical ranges are mapped peripheral devices (PCIe and NOR). > > Any idea if I'm doing something wrong or there can be a bug in memory code? > > Quite suspicious is that "Initmem setup node 0" prints one range where > are also peripherals, not just DRAM. Crash is on address 0xc01c8348 > which belongs to PCIe. > Yes I also find that "Initmem setup node 0" suspicious. However the crash address 0xc01c8348 is valid kernel address. That's a virtual address, not a physical address, so that's not PCIe. That's kernel linear mapping, so that's likely physical address 0x001c8348 offseted by PAGE_OFFSET which is 0xc0000000. Do you have a way to reproduce this problem under QEMU ? Thanks Christophe
On Sat, Sep 10, 2022 at 09:39:20AM +0000, Christophe Leroy wrote: > + Adding Mike who might help if the problem is around memblock. > > Le 08/09/2022 à 22:17, Pali Rohár a écrit : > > On Thursday 08 September 2022 17:35:11 Pali Rohár wrote: > >> On Thursday 08 September 2022 15:25:14 Christophe Leroy wrote: > >>> Le 08/08/2022 à 20:40, Pali Rohár a écrit : > >>>> On Friday 10 June 2022 00:24:20 Pali Rohár wrote: > >>>>> On Friday 20 May 2022 14:30:02 Pali Rohár wrote: > >>>>>> + linux-mm > >>>>>> > >>>>>> Do you know what are requirements for kernel to support non-contiguous > >>>>>> memory support and what is needed to enable it for 32-bit powerpc? > >>>>> > >>>>> Any hints? > >>>> > >>>> PING? > >>>> > >>> > >>> The tree following patches landed in powerpc/next branch, so they should > >>> soon be visible in linux-next too: > >>> > >>> fc06755e2562 ("powerpc/32: Drop a stale comment about reservation of > >>> gigantic pages") > >>> b0e0d68b1c52 ("powerpc/32: Allow fragmented physical memory") > >>> 0115953dcebe ("powerpc/32: Remove wii_memory_fixups()") > >> > >> Ou, nice! I will try to test it if it allows me to access more than 2GB > >> of RAM from 4GB DDR3 module with 32-bit addressing mode on P2020 CPU. > > > > Hello! Ok, I have tried it from powerpc/next branch, but seems it does > > not work. I'm getting just early kernel crash. > > > > [ 0.000000] CPU maps initialized for 1 thread per core > > [ 0.000000] (thread shift is 0) > > [ 0.000000] ----------------------------------------------------- > > [ 0.000000] phys_mem_size = 0xbe500000 > > [ 0.000000] dcache_bsize = 0x20 > > [ 0.000000] icache_bsize = 0x20 > > [ 0.000000] cpu_features = 0x0000000010010108 > > [ 0.000000] possible = 0x0000000010010108 > > [ 0.000000] always = 0x0000000010010108 > > [ 0.000000] cpu_user_features = 0x84e08000 0x08000000 > > [ 0.000000] mmu_features = 0x00020010 > > [ 0.000000] ----------------------------------------------------- > > mpc85xx_rdb_setup_arch() > > [ 0.000000] ioremap() called early from of_iomap+0x48/0x80. Use early_ioremap() instead > > [ 0.000000] MPC85xx RDB board from Freescale Semiconductor > > [ 0.000000] barrier-nospec: using isync; sync as speculation barrier > > [ 0.000000] barrier-nospec: patched 182 locations > > [ 0.000000] Top of RAM: 0xff700000, Total RAM: 0xbe500000 > > [ 0.000000] Memory hole size: 1042MB > > [ 0.000000] Zone ranges: > > [ 0.000000] Normal [mem 0x0000000000000000-0x000000002fffffff] > > [ 0.000000] HighMem [mem 0x0000000030000000-0x00000000ff6fffff] > > [ 0.000000] Movable zone start for each node > > [ 0.000000] Early memory node ranges > > [ 0.000000] node 0: [mem 0x0000000000000000-0x000000007fffffff] > > [ 0.000000] node 0: [mem 0x00000000c0200000-0x00000000eeffffff] > > [ 0.000000] node 0: [mem 0x00000000f0000000-0x00000000ff6fffff] > > [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000ff6fffff] > > [ 0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts > > [ 0.000000] percpu: Embedded 11 pages/cpu s14196 r8192 d22668 u45056 > > [ 0.000000] pcpu-alloc: s14196 r8192 d22668 u45056 alloc=11*4096 > > [ 0.000000] pcpu-alloc: [0] 0 [0] 1 > > [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 777792 > > [ 0.000000] Kernel command line: root=ubi0:rootfs rootfstype=ubifs ubi.mtd=rootfs,2048 rootflags=chk_data_crc rw console=ttyS0,115200 > > [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) > > [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) > > [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off > > [ 0.000000] Kernel attempted to read user page (7df58) - exploit attempt? (uid: 0) > > [ 0.000000] BUG: Unable to handle kernel data access on read at 0x0007df58 > > [ 0.000000] Faulting instruction address: 0xc01c8348 > > [ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1] > > [ 0.000000] BE PAGE_SIZE=4K SMP NR_CPUS=2 P2020RDB-PC > > [ 0.000000] Modules linked in: > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc2-0caacb197b677410bdac81bc34f05235+ #121 > > [ 0.000000] NIP: c01c8348 LR: c01cb2bc CTR: 0000000a > > [ 0.000000] REGS: c10d7e20 TRAP: 0300 Not tainted (6.0.0-rc2-0caacb197b677410bdac81bc34f05235+) > > [ 0.000000] MSR: 00021000 <CE,ME> CR: 48044224 XER: 00000000 > > [ 0.000000] DEAR: 0007df58 ESR: 00000000 > > [ 0.000000] GPR00: c01cb294 c10d7f10 c1045340 00000001 00000004 c112bcc0 00000015 eedf1000 > > [ 0.000000] GPR08: 00000003 0007df58 00000000 f0000000 28044228 00000200 00000000 00000000 > > [ 0.000000] GPR16: 00000000 00000000 00000000 0275cb7a c0000000 00000001 0000075f 00000000 > > [ 0.000000] GPR24: c1031004 00000000 00000000 00000001 c10f0000 eedf1000 00080000 00080000 > > [ 0.000000] NIP [c01c8348] free_unref_page_prepare.part.93+0x48/0x60 > > [ 0.000000] LR [c01cb2bc] free_unref_page+0x84/0x4b8 > > [ 0.000000] Call Trace: > > [ 0.000000] [c10d7f10] [eedf1000] 0xeedf1000 (unreliable) > > [ 0.000000] [c10d7f20] [c01cb294] free_unref_page+0x5c/0x4b8 > > [ 0.000000] [c10d7f70] [c1007644] mem_init+0xd0/0x194 > > [ 0.000000] [c10d7fa0] [c1000e4c] start_kernel+0x4c0/0x6d0 > > [ 0.000000] [c10d7ff0] [c00003e0] set_ivor+0x13c/0x178 > > [ 0.000000] Instruction dump: > > [ 0.000000] 552817be 5509103a 7d294214 55293830 7d4a4a14 812a003c 814a0038 5529002a > > [ 0.000000] 7c892050 5484c23a 5489eafa 548406fe <7d2a482e> 7d242430 5484077e 90870010 > > [ 0.000000] ---[ end trace 0000000000000000 ]--- > > [ 0.000000] > > [ 0.000000] Kernel panic - not syncing: Fatal exception > > [ 0.000000] Rebooting in 1 seconds.. > > [ 0.000000] System Halted, OK to turn off power > > > > 4GB DDR3 SODIMM module is set via Freescale LBC to the whole 4 GB > > address range. And on ranges: > > 0x0000_0000 - 0x7fff_ffff > > 0xc020_0000 - 0xeeff_ffff > > 0xf000_0000 - 0xff6f_ffff > > there is no peripheral device, they are free for DRAM. Between these > > physical ranges are mapped peripheral devices (PCIe and NOR). > > > > Any idea if I'm doing something wrong or there can be a bug in memory code? > > > > Quite suspicious is that "Initmem setup node 0" prints one range where > > are also peripherals, not just DRAM. Crash is on address 0xc01c8348 > > which belongs to PCIe. > > > > Yes I also find that "Initmem setup node 0" suspicious. > > However the crash address 0xc01c8348 is valid kernel address. That's a > virtual address, not a physical address, so that's not PCIe. That's > kernel linear mapping, so that's likely physical address 0x001c8348 > offseted by PAGE_OFFSET which is 0xc0000000. If I read the dump correctly, 0xc01c8348 is the PC of the instruction that crashed and the access was to 0x0007df58 which seem to well inside 0x0000_0000 - 0x7fff_ffff range. And the "Early memory node ranges" look consistent with the memory layout above. My guess would be that something went wrong in the linear map setup, but it won't hurt running with "memblock=debug" added to the kernel command line to see if there is anything suspicious there. > Do you have a way to reproduce this problem under QEMU ? > > Thanks > Christophe
On Monday 12 September 2022 15:48:05 Mike Rapoport wrote: > On Sat, Sep 10, 2022 at 09:39:20AM +0000, Christophe Leroy wrote: > > + Adding Mike who might help if the problem is around memblock. > > > > Le 08/09/2022 à 22:17, Pali Rohár a écrit : > > > On Thursday 08 September 2022 17:35:11 Pali Rohár wrote: > > >> On Thursday 08 September 2022 15:25:14 Christophe Leroy wrote: > > >>> Le 08/08/2022 à 20:40, Pali Rohár a écrit : > > >>>> On Friday 10 June 2022 00:24:20 Pali Rohár wrote: > > >>>>> On Friday 20 May 2022 14:30:02 Pali Rohár wrote: > > >>>>>> + linux-mm > > >>>>>> > > >>>>>> Do you know what are requirements for kernel to support non-contiguous > > >>>>>> memory support and what is needed to enable it for 32-bit powerpc? > > >>>>> > > >>>>> Any hints? > > >>>> > > >>>> PING? > > >>>> > > >>> > > >>> The tree following patches landed in powerpc/next branch, so they should > > >>> soon be visible in linux-next too: > > >>> > > >>> fc06755e2562 ("powerpc/32: Drop a stale comment about reservation of > > >>> gigantic pages") > > >>> b0e0d68b1c52 ("powerpc/32: Allow fragmented physical memory") > > >>> 0115953dcebe ("powerpc/32: Remove wii_memory_fixups()") > > >> > > >> Ou, nice! I will try to test it if it allows me to access more than 2GB > > >> of RAM from 4GB DDR3 module with 32-bit addressing mode on P2020 CPU. > > > > > > Hello! Ok, I have tried it from powerpc/next branch, but seems it does > > > not work. I'm getting just early kernel crash. > > > > > > [ 0.000000] CPU maps initialized for 1 thread per core > > > [ 0.000000] (thread shift is 0) > > > [ 0.000000] ----------------------------------------------------- > > > [ 0.000000] phys_mem_size = 0xbe500000 > > > [ 0.000000] dcache_bsize = 0x20 > > > [ 0.000000] icache_bsize = 0x20 > > > [ 0.000000] cpu_features = 0x0000000010010108 > > > [ 0.000000] possible = 0x0000000010010108 > > > [ 0.000000] always = 0x0000000010010108 > > > [ 0.000000] cpu_user_features = 0x84e08000 0x08000000 > > > [ 0.000000] mmu_features = 0x00020010 > > > [ 0.000000] ----------------------------------------------------- > > > mpc85xx_rdb_setup_arch() > > > [ 0.000000] ioremap() called early from of_iomap+0x48/0x80. Use early_ioremap() instead > > > [ 0.000000] MPC85xx RDB board from Freescale Semiconductor > > > [ 0.000000] barrier-nospec: using isync; sync as speculation barrier > > > [ 0.000000] barrier-nospec: patched 182 locations > > > [ 0.000000] Top of RAM: 0xff700000, Total RAM: 0xbe500000 > > > [ 0.000000] Memory hole size: 1042MB > > > [ 0.000000] Zone ranges: > > > [ 0.000000] Normal [mem 0x0000000000000000-0x000000002fffffff] > > > [ 0.000000] HighMem [mem 0x0000000030000000-0x00000000ff6fffff] > > > [ 0.000000] Movable zone start for each node > > > [ 0.000000] Early memory node ranges > > > [ 0.000000] node 0: [mem 0x0000000000000000-0x000000007fffffff] > > > [ 0.000000] node 0: [mem 0x00000000c0200000-0x00000000eeffffff] > > > [ 0.000000] node 0: [mem 0x00000000f0000000-0x00000000ff6fffff] > > > [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000ff6fffff] > > > [ 0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts > > > [ 0.000000] percpu: Embedded 11 pages/cpu s14196 r8192 d22668 u45056 > > > [ 0.000000] pcpu-alloc: s14196 r8192 d22668 u45056 alloc=11*4096 > > > [ 0.000000] pcpu-alloc: [0] 0 [0] 1 > > > [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 777792 > > > [ 0.000000] Kernel command line: root=ubi0:rootfs rootfstype=ubifs ubi.mtd=rootfs,2048 rootflags=chk_data_crc rw console=ttyS0,115200 > > > [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) > > > [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) > > > [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off > > > [ 0.000000] Kernel attempted to read user page (7df58) - exploit attempt? (uid: 0) > > > [ 0.000000] BUG: Unable to handle kernel data access on read at 0x0007df58 > > > [ 0.000000] Faulting instruction address: 0xc01c8348 > > > [ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1] > > > [ 0.000000] BE PAGE_SIZE=4K SMP NR_CPUS=2 P2020RDB-PC > > > [ 0.000000] Modules linked in: > > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc2-0caacb197b677410bdac81bc34f05235+ #121 > > > [ 0.000000] NIP: c01c8348 LR: c01cb2bc CTR: 0000000a > > > [ 0.000000] REGS: c10d7e20 TRAP: 0300 Not tainted (6.0.0-rc2-0caacb197b677410bdac81bc34f05235+) > > > [ 0.000000] MSR: 00021000 <CE,ME> CR: 48044224 XER: 00000000 > > > [ 0.000000] DEAR: 0007df58 ESR: 00000000 > > > [ 0.000000] GPR00: c01cb294 c10d7f10 c1045340 00000001 00000004 c112bcc0 00000015 eedf1000 > > > [ 0.000000] GPR08: 00000003 0007df58 00000000 f0000000 28044228 00000200 00000000 00000000 > > > [ 0.000000] GPR16: 00000000 00000000 00000000 0275cb7a c0000000 00000001 0000075f 00000000 > > > [ 0.000000] GPR24: c1031004 00000000 00000000 00000001 c10f0000 eedf1000 00080000 00080000 > > > [ 0.000000] NIP [c01c8348] free_unref_page_prepare.part.93+0x48/0x60 > > > [ 0.000000] LR [c01cb2bc] free_unref_page+0x84/0x4b8 > > > [ 0.000000] Call Trace: > > > [ 0.000000] [c10d7f10] [eedf1000] 0xeedf1000 (unreliable) > > > [ 0.000000] [c10d7f20] [c01cb294] free_unref_page+0x5c/0x4b8 > > > [ 0.000000] [c10d7f70] [c1007644] mem_init+0xd0/0x194 > > > [ 0.000000] [c10d7fa0] [c1000e4c] start_kernel+0x4c0/0x6d0 > > > [ 0.000000] [c10d7ff0] [c00003e0] set_ivor+0x13c/0x178 > > > [ 0.000000] Instruction dump: > > > [ 0.000000] 552817be 5509103a 7d294214 55293830 7d4a4a14 812a003c 814a0038 5529002a > > > [ 0.000000] 7c892050 5484c23a 5489eafa 548406fe <7d2a482e> 7d242430 5484077e 90870010 > > > [ 0.000000] ---[ end trace 0000000000000000 ]--- > > > [ 0.000000] > > > [ 0.000000] Kernel panic - not syncing: Fatal exception > > > [ 0.000000] Rebooting in 1 seconds.. > > > [ 0.000000] System Halted, OK to turn off power > > > > > > 4GB DDR3 SODIMM module is set via Freescale LBC to the whole 4 GB > > > address range. And on ranges: > > > 0x0000_0000 - 0x7fff_ffff > > > 0xc020_0000 - 0xeeff_ffff > > > 0xf000_0000 - 0xff6f_ffff > > > there is no peripheral device, they are free for DRAM. Between these > > > physical ranges are mapped peripheral devices (PCIe and NOR). > > > > > > Any idea if I'm doing something wrong or there can be a bug in memory code? > > > > > > Quite suspicious is that "Initmem setup node 0" prints one range where > > > are also peripherals, not just DRAM. Crash is on address 0xc01c8348 > > > which belongs to PCIe. > > > > > > > Yes I also find that "Initmem setup node 0" suspicious. > > > > However the crash address 0xc01c8348 is valid kernel address. That's a > > virtual address, not a physical address, so that's not PCIe. That's > > kernel linear mapping, so that's likely physical address 0x001c8348 > > offseted by PAGE_OFFSET which is 0xc0000000. > > If I read the dump correctly, 0xc01c8348 is the PC of the instruction that > crashed and the access was to 0x0007df58 which seem to well inside > 0x0000_0000 - 0x7fff_ffff range. I have tried to read and write memory at address 0x0007df58 in U-Boot and it works fine without any crash. I repeated that boot and it always failed with same errors at same address. I have also tried to use different 4GB DDR module (just in case if it is non-functional) but it failed on the same error on the same address. > And the "Early memory node ranges" look consistent with the memory layout > above. > > My guess would be that something went wrong in the linear map setup, but it > won't hurt running with "memblock=debug" added to the kernel command line > to see if there is anything suspicious there. Here is boot log on serial console with memblock=debug command line: [ 0.000000] memblock_alloc_try_nid: 8 bytes align=0x4 nid=-1 from=0x00000000 max_addr=0x00000000 smp_setup_cpu_maps+0x40/0x2b4 [ 0.000000] memblock_reserve: [0x2fff5d74-0x2fff5d7b] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] CPU maps initialized for 1 thread per core [ 0.000000] (thread shift is 0) [ 0.000000] memblock_phys_free: [0x2fff5d74-0x2fff5d7b] setup_arch+0x1bc/0x318 [ 0.000000] ----------------------------------------------------- [ 0.000000] phys_mem_size = 0xbe500000 [ 0.000000] dcache_bsize = 0x20 [ 0.000000] icache_bsize = 0x20 [ 0.000000] cpu_features = 0x0000000010010108 [ 0.000000] possible = 0x0000000010010108 [ 0.000000] always = 0x0000000010010108 [ 0.000000] cpu_user_features = 0x84e08000 0x08000000 [ 0.000000] mmu_features = 0x00020010 [ 0.000000] ----------------------------------------------------- [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2fff2000-0x2fff3fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2fff0000-0x2fff1fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffee000-0x2ffeffff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffec000-0x2ffedfff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffea000-0x2ffebfff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe8000-0x2ffe9fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe6000-0x2ffe7fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe4000-0x2ffe5fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe2000-0x2ffe3fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe0000-0x2ffe1fff] memblock_alloc_range_nid+0xe8/0x1b0 mpc85xx_rdb_setup_arch() [ 0.000000] ioremap() called early from of_iomap+0x48/0x80. Use early_ioremap() instead [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 max_addr=0x00000000 early_pte_alloc_kernel+0x3c/0x90 [ 0.000000] memblock_reserve: [0x2fff4000-0x2fff4fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] MPC85xx RDB board from Freescale Semiconductor [ 0.000000] barrier-nospec: using isync; sync as speculation barrier [ 0.000000] barrier-nospec: patched 182 locations [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 max_addr=0x00000000 early_pte_alloc_kernel+0x3c/0x90 [ 0.000000] memblock_reserve: [0x2ffdf000-0x2ffdffff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] Top of RAM: 0xff700000, Total RAM: 0xbe500000 [ 0.000000] Memory hole size: 1042MB [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] HighMem [mem 0x0000000030000000-0x00000000ff6fffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x000000007fffffff] [ 0.000000] node 0: [mem 0x00000000c0200000-0x00000000eeffffff] [ 0.000000] node 0: [mem 0x00000000f0000000-0x00000000ff6fffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000ff6fffff] [ 0.000000] memblock_alloc_try_nid_raw: 37675008 bytes align=0x20 nid=0 from=0x00000000 max_addr=0x00000000 free_area_init+0x890/0xc94 [ 0.000000] memblock_reserve: [0x2dbf1000-0x2ffdefff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=0 from=0x00000000 max_addr=0x00000000 setup_usemap+0x60/0xa0 [ 0.000000] memblock_reserve: [0x2fff5d00-0x2fff5d5f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 416 bytes align=0x20 nid=0 from=0x00000000 max_addr=0x00000000 setup_usemap+0x60/0xa0 [ 0.000000] memblock_reserve: [0x2fff5b60-0x2fff5cff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 mmu_context_init+0x38/0x154 [ 0.000000] memblock_reserve: [0x2fff5b40-0x2fff5b5f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 1024 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 mmu_context_init+0x7c/0x154 [ 0.000000] memblock_reserve: [0x2fff5740-0x2fff5b3f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 mmu_context_init+0xc4/0x154 [ 0.000000] memblock_reserve: [0x2fff5720-0x2fff573f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts [ 0.000000] memblock_alloc_try_nid: 116 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 start_kernel+0x194/0x6d0 [ 0.000000] memblock_reserve: [0x2fff56a0-0x2fff5713] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 116 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 start_kernel+0x1c0/0x6d0 [ 0.000000] memblock_reserve: [0x2fff5620-0x2fff5693] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_embed_first_chunk+0x314/0x7b4 [ 0.000000] memblock_reserve: [0x2dbf0000-0x2dbf0fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_embed_first_chunk+0x4d4/0x7b4 [ 0.000000] memblock_reserve: [0x2dbef000-0x2dbeffff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 90112 bytes align=0x1000 nid=-1 from=0x3fffffff max_addr=0x00000000 pcpu_embed_first_chunk+0x564/0x7b4 [ 0.000000] memblock_reserve: [0x2dbd9000-0x2dbeefff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_phys_free: [0x2dbe4000-0x2dbe3fff] pcpu_embed_first_chunk+0x680/0x7b4 [ 0.000000] memblock_phys_free: [0x2dbef000-0x2dbeefff] pcpu_embed_first_chunk+0x680/0x7b4 [ 0.000000] percpu: Embedded 11 pages/cpu s14196 r8192 d22668 u45056 [ 0.000000] memblock_alloc_try_nid: 4 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x37c/0x924 [ 0.000000] memblock_reserve: [0x2fff5d60-0x2fff5d63] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 4 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x3a4/0x924 [ 0.000000] memblock_reserve: [0x2fff5600-0x2fff5603] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x3cc/0x924 [ 0.000000] memblock_reserve: [0x2fff55e0-0x2fff55e7] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x3f4/0x924 [ 0.000000] memblock_reserve: [0x2fff55c0-0x2fff55c7] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] pcpu-alloc: s14196 r8192 d22668 u45056 alloc=11*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] memblock_alloc_try_nid: 136 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x7fc/0x924 [ 0.000000] memblock_reserve: [0x2fff5520-0x2fff55a7] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x64/0x2e0 [ 0.000000] memblock_reserve: [0x2fff54c0-0x2fff551f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 384 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xc4/0x2e0 [ 0.000000] memblock_reserve: [0x2fff5340-0x2fff54bf] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 388 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xf0/0x2e0 [ 0.000000] memblock_reserve: [0x2fff51a0-0x2fff5323] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x11c/0x2e0 [ 0.000000] memblock_reserve: [0x2fff5140-0x2fff519f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x64/0x2e0 [ 0.000000] memblock_reserve: [0x2fff50e0-0x2fff513f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 768 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xc4/0x2e0 [ 0.000000] memblock_reserve: [0x2dbd8d00-0x2dbd8fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 772 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xf0/0x2e0 [ 0.000000] memblock_reserve: [0x2dbd89e0-0x2dbd8ce3] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 192 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x11c/0x2e0 [ 0.000000] memblock_reserve: [0x2fff5020-0x2fff50df] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_phys_free: [0x2dbf0000-0x2dbf0fff] pcpu_embed_first_chunk+0x744/0x7b4 [ 0.000000] memblock_phys_free: [0x2dbef000-0x2dbeffff] pcpu_embed_first_chunk+0x754/0x7b4 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 777792 [ 0.000000] Kernel command line: root=ubi0:rootfs rootfstype=ubifs ubi.mtd=rootfs,2048 rootflags=chk_data_crc rw console=ttyS0,115200 memblock=debug [ 0.000000] memblock_alloc_try_nid: 524288 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_large_system_hash+0x1a4/0x2ec [ 0.000000] memblock_reserve: [0x2db589e0-0x2dbd89df] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) [ 0.000000] memblock_alloc_try_nid: 262144 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_large_system_hash+0x1a4/0x2ec [ 0.000000] memblock_reserve: [0x2db189e0-0x2db589df] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Kernel attempted to read user page (7df58) - exploit attempt? (uid: 0) [ 0.000000] BUG: Unable to handle kernel data access on read at 0x0007df58 [ 0.000000] Faulting instruction address: 0xc01c8348 [ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1] [ 0.000000] BE PAGE_SIZE=4K SMP NR_CPUS=2 P2020RDB-PC [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc2-0caacb197b677410bdac81bc34f05235+ #121 [ 0.000000] NIP: c01c8348 LR: c01cb2bc CTR: 0000000a [ 0.000000] REGS: c10d7e20 TRAP: 0300 Not tainted (6.0.0-rc2-0caacb197b677410bdac81bc34f05235+) [ 0.000000] MSR: 00021000 <CE,ME> CR: 48044224 XER: 00000000 [ 0.000000] DEAR: 0007df58 ESR: 00000000 [ 0.000000] GPR00: c01cb294 c10d7f10 c1045340 00000001 00000004 c112bcc0 00000015 eedf1000 [ 0.000000] GPR08: 00000003 0007df58 00000000 f0000000 28044228 00000200 00000000 00000000 [ 0.000000] GPR16: 00000000 00000000 00000000 0275cb7a c0000000 00000001 0000075f 00000000 [ 0.000000] GPR24: c1031004 00000000 00000000 00000001 c10f0000 eedf1000 00080000 00080000 [ 0.000000] NIP [c01c8348] free_unref_page_prepare.part.93+0x48/0x60 [ 0.000000] LR [c01cb2bc] free_unref_page+0x84/0x4b8 [ 0.000000] Call Trace: [ 0.000000] [c10d7f10] [eedf1000] 0xeedf1000 (unreliable) [ 0.000000] [c10d7f20] [c01cb294] free_unref_page+0x5c/0x4b8 [ 0.000000] [c10d7f70] [c1007644] mem_init+0xd0/0x194 [ 0.000000] [c10d7fa0] [c1000e4c] start_kernel+0x4c0/0x6d0 [ 0.000000] [c10d7ff0] [c00003e0] set_ivor+0x13c/0x178 [ 0.000000] Instruction dump: [ 0.000000] 552817be 5509103a 7d294214 55293830 7d4a4a14 812a003c 814a0038 5529002a [ 0.000000] 7c892050 5484c23a 5489eafa 548406fe <7d2a482e> 7d242430 5484077e 90870010 [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] [ 0.000000] Kernel panic - not syncing: Fatal exception [ 0.000000] Rebooting in 1 seconds.. [ 0.000000] System Halted, OK to turn off power Do you need something more for debug? > > Do you have a way to reproduce this problem under QEMU ? Well, I really do not know how to run it in QEMU. IIRC QEMU does not have support for P2020 processor. Is there any guidance? > > Thanks > > Christophe > > -- > Sincerely yours, > Mike.
Le 12/09/2022 à 23:16, Pali Rohár a écrit : > On Monday 12 September 2022 15:48:05 Mike Rapoport wrote: >> On Sat, Sep 10, 2022 at 09:39:20AM +0000, Christophe Leroy wrote: >>> + Adding Mike who might help if the problem is around memblock. >>> >>> Le 08/09/2022 à 22:17, Pali Rohár a écrit : >>>> On Thursday 08 September 2022 17:35:11 Pali Rohár wrote: >>>>> On Thursday 08 September 2022 15:25:14 Christophe Leroy wrote: >>>>>> Le 08/08/2022 à 20:40, Pali Rohár a écrit : >>>>>>> On Friday 10 June 2022 00:24:20 Pali Rohár wrote: >>>>>>>> On Friday 20 May 2022 14:30:02 Pali Rohár wrote: >>>>>>>>> + linux-mm >>>>>>>>> >>>>>>>>> Do you know what are requirements for kernel to support non-contiguous >>>>>>>>> memory support and what is needed to enable it for 32-bit powerpc? >>>>>>>> >>>>>>>> Any hints? >>>>>>> >>>>>>> PING? >>>>>>> >>>>>> >>>>>> The tree following patches landed in powerpc/next branch, so they should >>>>>> soon be visible in linux-next too: >>>>>> >>>>>> fc06755e2562 ("powerpc/32: Drop a stale comment about reservation of >>>>>> gigantic pages") >>>>>> b0e0d68b1c52 ("powerpc/32: Allow fragmented physical memory") >>>>>> 0115953dcebe ("powerpc/32: Remove wii_memory_fixups()") >>>>> >>>>> Ou, nice! I will try to test it if it allows me to access more than 2GB >>>>> of RAM from 4GB DDR3 module with 32-bit addressing mode on P2020 CPU. >>>> >>>> Hello! Ok, I have tried it from powerpc/next branch, but seems it does >>>> not work. I'm getting just early kernel crash. >>>> >>>> [ 0.000000] CPU maps initialized for 1 thread per core >>>> [ 0.000000] (thread shift is 0) >>>> [ 0.000000] ----------------------------------------------------- >>>> [ 0.000000] phys_mem_size = 0xbe500000 >>>> [ 0.000000] dcache_bsize = 0x20 >>>> [ 0.000000] icache_bsize = 0x20 >>>> [ 0.000000] cpu_features = 0x0000000010010108 >>>> [ 0.000000] possible = 0x0000000010010108 >>>> [ 0.000000] always = 0x0000000010010108 >>>> [ 0.000000] cpu_user_features = 0x84e08000 0x08000000 >>>> [ 0.000000] mmu_features = 0x00020010 >>>> [ 0.000000] ----------------------------------------------------- >>>> mpc85xx_rdb_setup_arch() >>>> [ 0.000000] ioremap() called early from of_iomap+0x48/0x80. Use early_ioremap() instead >>>> [ 0.000000] MPC85xx RDB board from Freescale Semiconductor >>>> [ 0.000000] barrier-nospec: using isync; sync as speculation barrier >>>> [ 0.000000] barrier-nospec: patched 182 locations >>>> [ 0.000000] Top of RAM: 0xff700000, Total RAM: 0xbe500000 >>>> [ 0.000000] Memory hole size: 1042MB >>>> [ 0.000000] Zone ranges: >>>> [ 0.000000] Normal [mem 0x0000000000000000-0x000000002fffffff] >>>> [ 0.000000] HighMem [mem 0x0000000030000000-0x00000000ff6fffff] >>>> [ 0.000000] Movable zone start for each node >>>> [ 0.000000] Early memory node ranges >>>> [ 0.000000] node 0: [mem 0x0000000000000000-0x000000007fffffff] >>>> [ 0.000000] node 0: [mem 0x00000000c0200000-0x00000000eeffffff] >>>> [ 0.000000] node 0: [mem 0x00000000f0000000-0x00000000ff6fffff] >>>> [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000ff6fffff] >>>> [ 0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts >>>> [ 0.000000] percpu: Embedded 11 pages/cpu s14196 r8192 d22668 u45056 >>>> [ 0.000000] pcpu-alloc: s14196 r8192 d22668 u45056 alloc=11*4096 >>>> [ 0.000000] pcpu-alloc: [0] 0 [0] 1 >>>> [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 777792 >>>> [ 0.000000] Kernel command line: root=ubi0:rootfs rootfstype=ubifs ubi.mtd=rootfs,2048 rootflags=chk_data_crc rw console=ttyS0,115200 >>>> [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) >>>> [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) >>>> [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off >>>> [ 0.000000] Kernel attempted to read user page (7df58) - exploit attempt? (uid: 0) >>>> [ 0.000000] BUG: Unable to handle kernel data access on read at 0x0007df58 >>>> [ 0.000000] Faulting instruction address: 0xc01c8348 >>>> [ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1] >>>> [ 0.000000] BE PAGE_SIZE=4K SMP NR_CPUS=2 P2020RDB-PC >>>> [ 0.000000] Modules linked in: >>>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc2-0caacb197b677410bdac81bc34f05235+ #121 >>>> [ 0.000000] NIP: c01c8348 LR: c01cb2bc CTR: 0000000a >>>> [ 0.000000] REGS: c10d7e20 TRAP: 0300 Not tainted (6.0.0-rc2-0caacb197b677410bdac81bc34f05235+) >>>> [ 0.000000] MSR: 00021000 <CE,ME> CR: 48044224 XER: 00000000 >>>> [ 0.000000] DEAR: 0007df58 ESR: 00000000 >>>> [ 0.000000] GPR00: c01cb294 c10d7f10 c1045340 00000001 00000004 c112bcc0 00000015 eedf1000 >>>> [ 0.000000] GPR08: 00000003 0007df58 00000000 f0000000 28044228 00000200 00000000 00000000 >>>> [ 0.000000] GPR16: 00000000 00000000 00000000 0275cb7a c0000000 00000001 0000075f 00000000 >>>> [ 0.000000] GPR24: c1031004 00000000 00000000 00000001 c10f0000 eedf1000 00080000 00080000 >>>> [ 0.000000] NIP [c01c8348] free_unref_page_prepare.part.93+0x48/0x60 >>>> [ 0.000000] LR [c01cb2bc] free_unref_page+0x84/0x4b8 >>>> [ 0.000000] Call Trace: >>>> [ 0.000000] [c10d7f10] [eedf1000] 0xeedf1000 (unreliable) >>>> [ 0.000000] [c10d7f20] [c01cb294] free_unref_page+0x5c/0x4b8 >>>> [ 0.000000] [c10d7f70] [c1007644] mem_init+0xd0/0x194 >>>> [ 0.000000] [c10d7fa0] [c1000e4c] start_kernel+0x4c0/0x6d0 >>>> [ 0.000000] [c10d7ff0] [c00003e0] set_ivor+0x13c/0x178 >>>> [ 0.000000] Instruction dump: >>>> [ 0.000000] 552817be 5509103a 7d294214 55293830 7d4a4a14 812a003c 814a0038 5529002a >>>> [ 0.000000] 7c892050 5484c23a 5489eafa 548406fe <7d2a482e> 7d242430 5484077e 90870010 >>>> [ 0.000000] ---[ end trace 0000000000000000 ]--- >>>> [ 0.000000] >>>> [ 0.000000] Kernel panic - not syncing: Fatal exception >>>> [ 0.000000] Rebooting in 1 seconds.. >>>> [ 0.000000] System Halted, OK to turn off power >>>> >>>> 4GB DDR3 SODIMM module is set via Freescale LBC to the whole 4 GB >>>> address range. And on ranges: >>>> 0x0000_0000 - 0x7fff_ffff >>>> 0xc020_0000 - 0xeeff_ffff >>>> 0xf000_0000 - 0xff6f_ffff >>>> there is no peripheral device, they are free for DRAM. Between these >>>> physical ranges are mapped peripheral devices (PCIe and NOR). >>>> >>>> Any idea if I'm doing something wrong or there can be a bug in memory code? >>>> >>>> Quite suspicious is that "Initmem setup node 0" prints one range where >>>> are also peripherals, not just DRAM. Crash is on address 0xc01c8348 >>>> which belongs to PCIe. >>>> >>> >>> Yes I also find that "Initmem setup node 0" suspicious. >>> >>> However the crash address 0xc01c8348 is valid kernel address. That's a >>> virtual address, not a physical address, so that's not PCIe. That's >>> kernel linear mapping, so that's likely physical address 0x001c8348 >>> offseted by PAGE_OFFSET which is 0xc0000000. >> >> If I read the dump correctly, 0xc01c8348 is the PC of the instruction that >> crashed and the access was to 0x0007df58 which seem to well inside >> 0x0000_0000 - 0x7fff_ffff range. > > I have tried to read and write memory at address 0x0007df58 in U-Boot > and it works fine without any crash. You are mixing physical and virtual addresses. With Uboot, you checked the Physical address. That corresponds to address 0xc007df58 in Linux. The Oops happens at virtual address 0x7df58 which is definitely invalid as it is below 0xc0000000. > > I repeated that boot and it always failed with same errors at same > address. I have also tried to use different 4GB DDR module (just in case > if it is non-functional) but it failed on the same error on the same > address. > >> And the "Early memory node ranges" look consistent with the memory layout >> above. >> >> My guess would be that something went wrong in the linear map setup, but it >> won't hurt running with "memblock=debug" added to the kernel command line >> to see if there is anything suspicious there. > > Here is boot log on serial console with memblock=debug command line: > ... > > Do you need something more for debug? Can you send me the 'vmlinux' used to generate the above Oops so that I can see exactly where we are in function mem_init(). And could you also try without CONFIG_HIGHMEM just in case. > >>> Do you have a way to reproduce this problem under QEMU ? > > Well, I really do not know how to run it in QEMU. IIRC QEMU does not > have support for P2020 processor. Is there any guidance? > I don't know. I guess there might be the same problem with any e500. But as far as I can see, the 8544 emulation on QEMU has a limit of 3GB and provides memory as a single block. Christophe
Le 13/09/2022 à 08:11, Christophe Leroy a écrit : > > > Le 12/09/2022 à 23:16, Pali Rohár a écrit : >>> >>> My guess would be that something went wrong in the linear map setup, >>> but it >>> won't hurt running with "memblock=debug" added to the kernel command >>> line >>> to see if there is anything suspicious there. >> >> Here is boot log on serial console with memblock=debug command line: >> > ... >> >> Do you need something more for debug? > > Can you send me the 'vmlinux' used to generate the above Oops so that I > can see exactly where we are in function mem_init(). > > And could you also try without CONFIG_HIGHMEM just in case. > I looked at the vmlinux you sent me, the problem is in the loop for highmem in mem_init(). It crashes in the call to free_highmem_page() #ifdef CONFIG_HIGHMEM { unsigned long pfn, highmem_mapnr; highmem_mapnr = lowmem_end_addr >> PAGE_SHIFT; for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) { phys_addr_t paddr = (phys_addr_t)pfn << PAGE_SHIFT; struct page *page = pfn_to_page(pfn); if (!memblock_is_reserved(paddr)) free_highmem_page(page); } } #endif /* CONFIG_HIGHMEM */ As far as I can see in the memblock debug lines, the holes don't seem to be marked as reserved by memblock. So it is above valid ? Other architectures seem to do differently. Can you try by replacing !memblock_is_reserved(paddr) by memblock_is_memory(paddr) ? Thanks Christophe
On Tue, Sep 13, 2022 at 02:36:13PM +0200, Christophe Leroy wrote: > > > Le 13/09/2022 à 08:11, Christophe Leroy a écrit : > > > > > > Le 12/09/2022 à 23:16, Pali Rohár a écrit : > > > > > > > > My guess would be that something went wrong in the linear map > > > > setup, but it > > > > won't hurt running with "memblock=debug" added to the kernel > > > > command line > > > > to see if there is anything suspicious there. > > > > > > Here is boot log on serial console with memblock=debug command line: > > > > > ... > > > > > > Do you need something more for debug? > > > > Can you send me the 'vmlinux' used to generate the above Oops so that I > > can see exactly where we are in function mem_init(). > > > > And could you also try without CONFIG_HIGHMEM just in case. > > > > I looked at the vmlinux you sent me, the problem is in the loop for highmem > in mem_init(). It crashes in the call to free_highmem_page() > > #ifdef CONFIG_HIGHMEM > { > unsigned long pfn, highmem_mapnr; > > highmem_mapnr = lowmem_end_addr >> PAGE_SHIFT; > for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) { > phys_addr_t paddr = (phys_addr_t)pfn << PAGE_SHIFT; > struct page *page = pfn_to_page(pfn); > if (!memblock_is_reserved(paddr)) > free_highmem_page(page); > } > } > #endif /* CONFIG_HIGHMEM */ > > > As far as I can see in the memblock debug lines, the holes don't seem to be > marked as reserved by memblock. So it is above valid ? Other architectures > seem to do differently. > > Can you try by replacing !memblock_is_reserved(paddr) by > memblock_is_memory(paddr) ? The holes should not be marked as reserved, we just need to loop over the memory ranges rather than over pfns. Then the holes will be taken into account. I believe arm and xtensa got this right: (from arch/arm/mm/init.c) static void __init free_highpages(void) { #ifdef CONFIG_HIGHMEM unsigned long max_low = max_low_pfn; phys_addr_t range_start, range_end; u64 i; /* set highmem page free */ for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE, &range_start, &range_end, NULL) { unsigned long start = PFN_UP(range_start); unsigned long end = PFN_DOWN(range_end); /* Ignore complete lowmem entries */ if (end <= max_low) continue; /* Truncate partial highmem entries */ if (start < max_low) start = max_low; for (; start < end; start++) free_highmem_page(pfn_to_page(start)); } #endif } > Thanks > Christophe >
Le 14/09/2022 à 11:32, Mike Rapoport a écrit : > On Tue, Sep 13, 2022 at 02:36:13PM +0200, Christophe Leroy wrote: >> >> >> Le 13/09/2022 à 08:11, Christophe Leroy a écrit : >>> >>> >>> Le 12/09/2022 à 23:16, Pali Rohár a écrit : >>>>> >>>>> My guess would be that something went wrong in the linear map >>>>> setup, but it >>>>> won't hurt running with "memblock=debug" added to the kernel >>>>> command line >>>>> to see if there is anything suspicious there. >>>> >>>> Here is boot log on serial console with memblock=debug command line: >>>> >>> ... >>>> >>>> Do you need something more for debug? >>> >>> Can you send me the 'vmlinux' used to generate the above Oops so that I >>> can see exactly where we are in function mem_init(). >>> >>> And could you also try without CONFIG_HIGHMEM just in case. >>> >> >> I looked at the vmlinux you sent me, the problem is in the loop for highmem >> in mem_init(). It crashes in the call to free_highmem_page() >> >> #ifdef CONFIG_HIGHMEM >> { >> unsigned long pfn, highmem_mapnr; >> >> highmem_mapnr = lowmem_end_addr >> PAGE_SHIFT; >> for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) { >> phys_addr_t paddr = (phys_addr_t)pfn << PAGE_SHIFT; >> struct page *page = pfn_to_page(pfn); >> if (!memblock_is_reserved(paddr)) >> free_highmem_page(page); >> } >> } >> #endif /* CONFIG_HIGHMEM */ >> >> >> As far as I can see in the memblock debug lines, the holes don't seem to be >> marked as reserved by memblock. So it is above valid ? Other architectures >> seem to do differently. >> >> Can you try by replacing !memblock_is_reserved(paddr) by >> memblock_is_memory(paddr) ? > > The holes should not be marked as reserved, we just need to loop over the > memory ranges rather than over pfns. Then the holes will be taken into > account. > > I believe arm and xtensa got this right: > > (from arch/arm/mm/init.c) > > static void __init free_highpages(void) > { > #ifdef CONFIG_HIGHMEM > unsigned long max_low = max_low_pfn; > phys_addr_t range_start, range_end; > u64 i; > > /* set highmem page free */ > for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE, > &range_start, &range_end, NULL) { > unsigned long start = PFN_UP(range_start); > unsigned long end = PFN_DOWN(range_end); > > /* Ignore complete lowmem entries */ > if (end <= max_low) > continue; > > /* Truncate partial highmem entries */ > if (start < max_low) > start = max_low; > > for (; start < end; start++) > free_highmem_page(pfn_to_page(start)); > } > #endif > } > And what about the way MIPS does it ? static inline void __init mem_init_free_highmem(void) { #ifdef CONFIG_HIGHMEM unsigned long tmp; if (cpu_has_dc_aliases) return; for (tmp = highstart_pfn; tmp < highend_pfn; tmp++) { struct page *page = pfn_to_page(tmp); if (!memblock_is_memory(PFN_PHYS(tmp))) SetPageReserved(page); else free_highmem_page(page); } #endif } Christophe
On September 14, 2022 10:43:52 AM GMT+01:00, Christophe Leroy <christophe.leroy@csgroup.eu> wrote: > > >Le 14/09/2022 à 11:32, Mike Rapoport a écrit : >> On Tue, Sep 13, 2022 at 02:36:13PM +0200, Christophe Leroy wrote: >>> >>> >>> Le 13/09/2022 à 08:11, Christophe Leroy a écrit : >>>> >>>> >>>> Le 12/09/2022 à 23:16, Pali Rohár a écrit : >>>>>> >>>>>> My guess would be that something went wrong in the linear map >>>>>> setup, but it >>>>>> won't hurt running with "memblock=debug" added to the kernel >>>>>> command line >>>>>> to see if there is anything suspicious there. >>>>> >>>>> Here is boot log on serial console with memblock=debug command line: >>>>> >>>> ... >>>>> >>>>> Do you need something more for debug? >>>> >>>> Can you send me the 'vmlinux' used to generate the above Oops so that I >>>> can see exactly where we are in function mem_init(). >>>> >>>> And could you also try without CONFIG_HIGHMEM just in case. >>>> >>> >>> I looked at the vmlinux you sent me, the problem is in the loop for highmem >>> in mem_init(). It crashes in the call to free_highmem_page() >>> >>> #ifdef CONFIG_HIGHMEM >>> { >>> unsigned long pfn, highmem_mapnr; >>> >>> highmem_mapnr = lowmem_end_addr >> PAGE_SHIFT; >>> for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) { >>> phys_addr_t paddr = (phys_addr_t)pfn << PAGE_SHIFT; >>> struct page *page = pfn_to_page(pfn); >>> if (!memblock_is_reserved(paddr)) >>> free_highmem_page(page); >>> } >>> } >>> #endif /* CONFIG_HIGHMEM */ >>> >>> >>> As far as I can see in the memblock debug lines, the holes don't seem to be >>> marked as reserved by memblock. So it is above valid ? Other architectures >>> seem to do differently. >>> >>> Can you try by replacing !memblock_is_reserved(paddr) by >>> memblock_is_memory(paddr) ? >> >> The holes should not be marked as reserved, we just need to loop over the >> memory ranges rather than over pfns. Then the holes will be taken into >> account. >> >> I believe arm and xtensa got this right: >> >> (from arch/arm/mm/init.c) >> >> static void __init free_highpages(void) >> { >> #ifdef CONFIG_HIGHMEM >> unsigned long max_low = max_low_pfn; >> phys_addr_t range_start, range_end; >> u64 i; >> >> /* set highmem page free */ >> for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE, >> &range_start, &range_end, NULL) { >> unsigned long start = PFN_UP(range_start); >> unsigned long end = PFN_DOWN(range_end); >> >> /* Ignore complete lowmem entries */ >> if (end <= max_low) >> continue; >> >> /* Truncate partial highmem entries */ >> if (start < max_low) >> start = max_low; >> >> for (; start < end; start++) >> free_highmem_page(pfn_to_page(start)); >> } >> #endif >> } >> > > >And what about the way MIPS does it ? > >static inline void __init mem_init_free_highmem(void) >{ >#ifdef CONFIG_HIGHMEM > unsigned long tmp; > > if (cpu_has_dc_aliases) > return; > > for (tmp = highstart_pfn; tmp < highend_pfn; tmp++) { > struct page *page = pfn_to_page(tmp); > > if (!memblock_is_memory(PFN_PHYS(tmp))) > SetPageReserved(page); > else > free_highmem_page(page); > } >#endif >} This iterates over all PFNs in the highmem range and skips those in holes. for_each_free_mem_range() skips the holes altogether. Largely, I think we need to move, say, arm's version to mm/ and use it everywhere, except, perhaps, x86. >Christophe
On Wednesday 14 September 2022 16:55:04 Mike Rapoport wrote: > On September 14, 2022 10:43:52 AM GMT+01:00, Christophe Leroy <christophe.leroy@csgroup.eu> wrote: > > > > > >Le 14/09/2022 à 11:32, Mike Rapoport a écrit : > >> On Tue, Sep 13, 2022 at 02:36:13PM +0200, Christophe Leroy wrote: > >>> > >>> > >>> Le 13/09/2022 à 08:11, Christophe Leroy a écrit : > >>>> > >>>> > >>>> Le 12/09/2022 à 23:16, Pali Rohár a écrit : > >>>>>> > >>>>>> My guess would be that something went wrong in the linear map > >>>>>> setup, but it > >>>>>> won't hurt running with "memblock=debug" added to the kernel > >>>>>> command line > >>>>>> to see if there is anything suspicious there. > >>>>> > >>>>> Here is boot log on serial console with memblock=debug command line: > >>>>> > >>>> ... > >>>>> > >>>>> Do you need something more for debug? > >>>> > >>>> Can you send me the 'vmlinux' used to generate the above Oops so that I > >>>> can see exactly where we are in function mem_init(). > >>>> > >>>> And could you also try without CONFIG_HIGHMEM just in case. Hello! I disabled CONFIG_HIGHMEM and there is no crash anymore. But kernel see only 761160 kB of RAM, which is less than 3GB. I guess this is expected. > >>>> > >>> > >>> I looked at the vmlinux you sent me, the problem is in the loop for highmem > >>> in mem_init(). It crashes in the call to free_highmem_page() > >>> > >>> #ifdef CONFIG_HIGHMEM > >>> { > >>> unsigned long pfn, highmem_mapnr; > >>> > >>> highmem_mapnr = lowmem_end_addr >> PAGE_SHIFT; > >>> for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) { > >>> phys_addr_t paddr = (phys_addr_t)pfn << PAGE_SHIFT; > >>> struct page *page = pfn_to_page(pfn); > >>> if (!memblock_is_reserved(paddr)) > >>> free_highmem_page(page); > >>> } > >>> } > >>> #endif /* CONFIG_HIGHMEM */ > >>> > >>> > >>> As far as I can see in the memblock debug lines, the holes don't seem to be > >>> marked as reserved by memblock. So it is above valid ? Other architectures > >>> seem to do differently. > >>> > >>> Can you try by replacing !memblock_is_reserved(paddr) by > >>> memblock_is_memory(paddr) ? I enabled CONFIG_HIGHMEM again, applied this change and kernel does not crash too anymore. And it sees 3062896 kB of memory (in 'free' output). So seems that this change fixed it. I tried simple C program for allocating memory via malloc() and it successfully allocated 2800 MB. If it tried to request/allocate more then kernel started OOM killer which killed that program gracefully. No kernel or HW crash. Here is bootlog: [ 0.000000] memblock_alloc_try_nid: 8 bytes align=0x4 nid=-1 from=0x00000000 max_addr=0x00000000 smp_setup_cpu_maps+0x40/0x2b4 [ 0.000000] memblock_reserve: [0x2fff5d74-0x2fff5d7b] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] CPU maps initialized for 1 thread per core [ 0.000000] (thread shift is 0) [ 0.000000] memblock_phys_free: [0x2fff5d74-0x2fff5d7b] setup_arch+0x1bc/0x318 [ 0.000000] ----------------------------------------------------- [ 0.000000] phys_mem_size = 0xbe500000 [ 0.000000] dcache_bsize = 0x20 [ 0.000000] icache_bsize = 0x20 [ 0.000000] cpu_features = 0x0000000010010108 [ 0.000000] possible = 0x0000000010010108 [ 0.000000] always = 0x0000000010010108 [ 0.000000] cpu_user_features = 0x84e08000 0x08000000 [ 0.000000] mmu_features = 0x00020010 [ 0.000000] ----------------------------------------------------- [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2fff2000-0x2fff3fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2fff0000-0x2fff1fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffee000-0x2ffeffff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffec000-0x2ffedfff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffea000-0x2ffebfff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe8000-0x2ffe9fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe6000-0x2ffe7fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe4000-0x2ffe5fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe2000-0x2ffe3fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe0000-0x2ffe1fff] memblock_alloc_range_nid+0xe8/0x1b0 mpc85xx_rdb_setup_arch() [ 0.000000] ioremap() called early from of_iomap+0x48/0x80. Use early_ioremap() instead [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 max_addr=0x00000000 early_pte_alloc_kernel+0x3c/0x90 [ 0.000000] memblock_reserve: [0x2fff4000-0x2fff4fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] MPC85xx RDB board from Freescale Semiconductor [ 0.000000] barrier-nospec: using isync; sync as speculation barrier [ 0.000000] barrier-nospec: patched 182 locations [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 max_addr=0x00000000 early_pte_alloc_kernel+0x3c/0x90 [ 0.000000] memblock_reserve: [0x2ffdf000-0x2ffdffff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] Top of RAM: 0xff700000, Total RAM: 0xbe500000 [ 0.000000] Memory hole size: 1042MB [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] HighMem [mem 0x0000000030000000-0x00000000ff6fffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x000000007fffffff] [ 0.000000] node 0: [mem 0x00000000c0200000-0x00000000eeffffff] [ 0.000000] node 0: [mem 0x00000000f0000000-0x00000000ff6fffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000ff6fffff] [ 0.000000] memblock_alloc_try_nid_raw: 37675008 bytes align=0x20 nid=0 from=0x00000000 max_addr=0x00000000 free_area_init+0x890/0xc94 [ 0.000000] memblock_reserve: [0x2dbf1000-0x2ffdefff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=0 from=0x00000000 max_addr=0x00000000 setup_usemap+0x60/0xa0 [ 0.000000] memblock_reserve: [0x2fff5d00-0x2fff5d5f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 416 bytes align=0x20 nid=0 from=0x00000000 max_addr=0x00000000 setup_usemap+0x60/0xa0 [ 0.000000] memblock_reserve: [0x2fff5b60-0x2fff5cff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 mmu_context_init+0x38/0x154 [ 0.000000] memblock_reserve: [0x2fff5b40-0x2fff5b5f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 1024 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 mmu_context_init+0x7c/0x154 [ 0.000000] memblock_reserve: [0x2fff5740-0x2fff5b3f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 mmu_context_init+0xc4/0x154 [ 0.000000] memblock_reserve: [0x2fff5720-0x2fff573f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts [ 0.000000] memblock_alloc_try_nid: 111 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 start_kernel+0x194/0x6d0 [ 0.000000] memblock_reserve: [0x2fff56a0-0x2fff570e] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 111 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 start_kernel+0x1c0/0x6d0 [ 0.000000] memblock_reserve: [0x2fff5620-0x2fff568e] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_embed_first_chunk+0x314/0x7b4 [ 0.000000] memblock_reserve: [0x2dbf0000-0x2dbf0fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_embed_first_chunk+0x4d4/0x7b4 [ 0.000000] memblock_reserve: [0x2dbef000-0x2dbeffff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 90112 bytes align=0x1000 nid=-1 from=0x3fffffff max_addr=0x00000000 pcpu_embed_first_chunk+0x564/0x7b4 [ 0.000000] memblock_reserve: [0x2dbd9000-0x2dbeefff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_phys_free: [0x2dbe4000-0x2dbe3fff] pcpu_embed_first_chunk+0x680/0x7b4 [ 0.000000] memblock_phys_free: [0x2dbef000-0x2dbeefff] pcpu_embed_first_chunk+0x680/0x7b4 [ 0.000000] percpu: Embedded 11 pages/cpu s14196 r8192 d22668 u45056 [ 0.000000] memblock_alloc_try_nid: 4 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x37c/0x924 [ 0.000000] memblock_reserve: [0x2fff5d60-0x2fff5d63] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 4 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x3a4/0x924 [ 0.000000] memblock_reserve: [0x2fff5600-0x2fff5603] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x3cc/0x924 [ 0.000000] memblock_reserve: [0x2fff55e0-0x2fff55e7] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x3f4/0x924 [ 0.000000] memblock_reserve: [0x2fff55c0-0x2fff55c7] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] pcpu-alloc: s14196 r8192 d22668 u45056 alloc=11*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] memblock_alloc_try_nid: 136 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x7fc/0x924 [ 0.000000] memblock_reserve: [0x2fff5520-0x2fff55a7] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x64/0x2e0 [ 0.000000] memblock_reserve: [0x2fff54c0-0x2fff551f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 384 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xc4/0x2e0 [ 0.000000] memblock_reserve: [0x2fff5340-0x2fff54bf] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 388 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xf0/0x2e0 [ 0.000000] memblock_reserve: [0x2fff51a0-0x2fff5323] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x11c/0x2e0 [ 0.000000] memblock_reserve: [0x2fff5140-0x2fff519f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x64/0x2e0 [ 0.000000] memblock_reserve: [0x2fff50e0-0x2fff513f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 768 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xc4/0x2e0 [ 0.000000] memblock_reserve: [0x2dbd8d00-0x2dbd8fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 772 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xf0/0x2e0 [ 0.000000] memblock_reserve: [0x2dbd89e0-0x2dbd8ce3] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 192 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x11c/0x2e0 [ 0.000000] memblock_reserve: [0x2fff5020-0x2fff50df] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_phys_free: [0x2dbf0000-0x2dbf0fff] pcpu_embed_first_chunk+0x744/0x7b4 [ 0.000000] memblock_phys_free: [0x2dbef000-0x2dbeffff] pcpu_embed_first_chunk+0x754/0x7b4 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 777792 [ 0.000000] Kernel command line: root=ubi0:rootfs rootfstype=ubifs ubi.mtd=rootfs rootflags=chk_data_crc rw console=ttyS0,115200 memblock=debug [ 0.000000] memblock_alloc_try_nid: 524288 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_large_system_hash+0x1a4/0x2ec [ 0.000000] memblock_reserve: [0x2db589e0-0x2dbd89df] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) [ 0.000000] memblock_alloc_try_nid: 262144 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_large_system_hash+0x1a4/0x2ec [ 0.000000] memblock_reserve: [0x2db189e0-0x2db589df] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Kernel virtual memory layout: [ 0.000000] * 0xffbbf000..0xfffff000 : fixmap [ 0.000000] * 0xff400000..0xff800000 : highmem PTEs [ 0.000000] * 0xff3fe000..0xff400000 : early ioremap [ 0.000000] * 0xf1000000..0xff3fe000 : vmalloc & ioremap [ 0.000000] Memory: 3062620K/3118080K available (10732K kernel code, 712K rwdata, 2044K rodata, 276K init, 287K bss, 55460K reserved, 0K cma-reserved, 2331648K highmem) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 > >> > >> The holes should not be marked as reserved, we just need to loop over the > >> memory ranges rather than over pfns. Then the holes will be taken into > >> account. > >> > >> I believe arm and xtensa got this right: > >> > >> (from arch/arm/mm/init.c) > >> > >> static void __init free_highpages(void) > >> { > >> #ifdef CONFIG_HIGHMEM > >> unsigned long max_low = max_low_pfn; > >> phys_addr_t range_start, range_end; > >> u64 i; > >> > >> /* set highmem page free */ > >> for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE, > >> &range_start, &range_end, NULL) { > >> unsigned long start = PFN_UP(range_start); > >> unsigned long end = PFN_DOWN(range_end); > >> > >> /* Ignore complete lowmem entries */ > >> if (end <= max_low) > >> continue; > >> > >> /* Truncate partial highmem entries */ > >> if (start < max_low) > >> start = max_low; > >> > >> for (; start < end; start++) > >> free_highmem_page(pfn_to_page(start)); > >> } > >> #endif > >> } > >> > > > > > >And what about the way MIPS does it ? > > > >static inline void __init mem_init_free_highmem(void) > >{ > >#ifdef CONFIG_HIGHMEM > > unsigned long tmp; > > > > if (cpu_has_dc_aliases) > > return; > > > > for (tmp = highstart_pfn; tmp < highend_pfn; tmp++) { > > struct page *page = pfn_to_page(tmp); > > > > if (!memblock_is_memory(PFN_PHYS(tmp))) > > SetPageReserved(page); > > else > > free_highmem_page(page); > > } > >#endif > >} > > This iterates over all PFNs in the highmem range and skips those in holes. > for_each_free_mem_range() skips the holes altogether. > > Largely, I think we need to move, say, arm's version to mm/ and use it everywhere, except, perhaps, x86. I tried to replace quoted powerpc CONFIG_HIGHMEM code by above arm code and it worked fine too! No kernel crash anymore. But 'free' see only 3062888 kB of total memory. Which is less then with the first workaround. Here is bootlog: [ 0.000000] memblock_alloc_try_nid: 8 bytes align=0x4 nid=-1 from=0x00000000 max_addr=0x00000000 smp_setup_cpu_maps+0x40/0x2b4 [ 0.000000] memblock_reserve: [0x2fff5d74-0x2fff5d7b] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] CPU maps initialized for 1 thread per core [ 0.000000] (thread shift is 0) [ 0.000000] memblock_phys_free: [0x2fff5d74-0x2fff5d7b] setup_arch+0x1bc/0x318 [ 0.000000] ----------------------------------------------------- [ 0.000000] phys_mem_size = 0xbe500000 [ 0.000000] dcache_bsize = 0x20 [ 0.000000] icache_bsize = 0x20 [ 0.000000] cpu_features = 0x0000000010010108 [ 0.000000] possible = 0x0000000010010108 [ 0.000000] always = 0x0000000010010108 [ 0.000000] cpu_user_features = 0x84e08000 0x08000000 [ 0.000000] mmu_features = 0x00020010 [ 0.000000] ----------------------------------------------------- [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2fff2000-0x2fff3fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2fff0000-0x2fff1fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffee000-0x2ffeffff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffec000-0x2ffedfff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffea000-0x2ffebfff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe8000-0x2ffe9fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe6000-0x2ffe7fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe4000-0x2ffe5fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe2000-0x2ffe3fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8192 bytes align=0x2000 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_stack+0x2c/0x60 [ 0.000000] memblock_reserve: [0x2ffe0000-0x2ffe1fff] memblock_alloc_range_nid+0xe8/0x1b0 mpc85xx_rdb_setup_arch() [ 0.000000] ioremap() called early from of_iomap+0x48/0x80. Use early_ioremap() instead [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 max_addr=0x00000000 early_pte_alloc_kernel+0x3c/0x90 [ 0.000000] memblock_reserve: [0x2fff4000-0x2fff4fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] MPC85xx RDB board from Freescale Semiconductor [ 0.000000] barrier-nospec: using isync; sync as speculation barrier [ 0.000000] barrier-nospec: patched 182 locations [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 max_addr=0x00000000 early_pte_alloc_kernel+0x3c/0x90 [ 0.000000] memblock_reserve: [0x2ffdf000-0x2ffdffff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] Top of RAM: 0xff700000, Total RAM: 0xbe500000 [ 0.000000] Memory hole size: 1042MB [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] HighMem [mem 0x0000000030000000-0x00000000ff6fffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x000000007fffffff] [ 0.000000] node 0: [mem 0x00000000c0200000-0x00000000eeffffff] [ 0.000000] node 0: [mem 0x00000000f0000000-0x00000000ff6fffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000ff6fffff] [ 0.000000] memblock_alloc_try_nid_raw: 37675008 bytes align=0x20 nid=0 from=0x00000000 max_addr=0x00000000 free_area_init+0x890/0xc94 [ 0.000000] memblock_reserve: [0x2dbf1000-0x2ffdefff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=0 from=0x00000000 max_addr=0x00000000 setup_usemap+0x60/0xa0 [ 0.000000] memblock_reserve: [0x2fff5d00-0x2fff5d5f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 416 bytes align=0x20 nid=0 from=0x00000000 max_addr=0x00000000 setup_usemap+0x60/0xa0 [ 0.000000] memblock_reserve: [0x2fff5b60-0x2fff5cff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 mmu_context_init+0x38/0x154 [ 0.000000] memblock_reserve: [0x2fff5b40-0x2fff5b5f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 1024 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 mmu_context_init+0x7c/0x154 [ 0.000000] memblock_reserve: [0x2fff5740-0x2fff5b3f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 mmu_context_init+0xc4/0x154 [ 0.000000] memblock_reserve: [0x2fff5720-0x2fff573f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts [ 0.000000] memblock_alloc_try_nid: 111 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 start_kernel+0x194/0x6d0 [ 0.000000] memblock_reserve: [0x2fff56a0-0x2fff570e] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 111 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 start_kernel+0x1c0/0x6d0 [ 0.000000] memblock_reserve: [0x2fff5620-0x2fff568e] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_embed_first_chunk+0x314/0x7b4 [ 0.000000] memblock_reserve: [0x2dbf0000-0x2dbf0fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_embed_first_chunk+0x4d4/0x7b4 [ 0.000000] memblock_reserve: [0x2dbef000-0x2dbeffff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 90112 bytes align=0x1000 nid=-1 from=0x3fffffff max_addr=0x00000000 pcpu_embed_first_chunk+0x564/0x7b4 [ 0.000000] memblock_reserve: [0x2dbd9000-0x2dbeefff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_phys_free: [0x2dbe4000-0x2dbe3fff] pcpu_embed_first_chunk+0x680/0x7b4 [ 0.000000] memblock_phys_free: [0x2dbef000-0x2dbeefff] pcpu_embed_first_chunk+0x680/0x7b4 [ 0.000000] percpu: Embedded 11 pages/cpu s14196 r8192 d22668 u45056 [ 0.000000] memblock_alloc_try_nid: 4 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x37c/0x924 [ 0.000000] memblock_reserve: [0x2fff5d60-0x2fff5d63] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 4 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x3a4/0x924 [ 0.000000] memblock_reserve: [0x2fff5600-0x2fff5603] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x3cc/0x924 [ 0.000000] memblock_reserve: [0x2fff55e0-0x2fff55e7] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 8 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x3f4/0x924 [ 0.000000] memblock_reserve: [0x2fff55c0-0x2fff55c7] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] pcpu-alloc: s14196 r8192 d22668 u45056 alloc=11*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] memblock_alloc_try_nid: 136 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_setup_first_chunk+0x7fc/0x924 [ 0.000000] memblock_reserve: [0x2fff5520-0x2fff55a7] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x64/0x2e0 [ 0.000000] memblock_reserve: [0x2fff54c0-0x2fff551f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 384 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xc4/0x2e0 [ 0.000000] memblock_reserve: [0x2fff5340-0x2fff54bf] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 388 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xf0/0x2e0 [ 0.000000] memblock_reserve: [0x2fff51a0-0x2fff5323] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x11c/0x2e0 [ 0.000000] memblock_reserve: [0x2fff5140-0x2fff519f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 96 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x64/0x2e0 [ 0.000000] memblock_reserve: [0x2fff50e0-0x2fff513f] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 768 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xc4/0x2e0 [ 0.000000] memblock_reserve: [0x2dbd8d00-0x2dbd8fff] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 772 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0xf0/0x2e0 [ 0.000000] memblock_reserve: [0x2dbd89e0-0x2dbd8ce3] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_alloc_try_nid: 192 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 pcpu_alloc_first_chunk+0x11c/0x2e0 [ 0.000000] memblock_reserve: [0x2fff5020-0x2fff50df] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] memblock_phys_free: [0x2dbf0000-0x2dbf0fff] pcpu_embed_first_chunk+0x744/0x7b4 [ 0.000000] memblock_phys_free: [0x2dbef000-0x2dbeffff] pcpu_embed_first_chunk+0x754/0x7b4 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 777792 [ 0.000000] Kernel command line: root=ubi0:rootfs rootfstype=ubifs ubi.mtd=rootfs rootflags=chk_data_crc rw console=ttyS0,115200 memblock=debug [ 0.000000] memblock_alloc_try_nid: 524288 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_large_system_hash+0x1a4/0x2ec [ 0.000000] memblock_reserve: [0x2db589e0-0x2dbd89df] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) [ 0.000000] memblock_alloc_try_nid: 262144 bytes align=0x20 nid=-1 from=0x00000000 max_addr=0x00000000 alloc_large_system_hash+0x1a4/0x2ec [ 0.000000] memblock_reserve: [0x2db189e0-0x2db589df] memblock_alloc_range_nid+0xe8/0x1b0 [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Kernel virtual memory layout: [ 0.000000] * 0xffbbf000..0xfffff000 : fixmap [ 0.000000] * 0xff400000..0xff800000 : highmem PTEs [ 0.000000] * 0xff3fe000..0xff400000 : early ioremap [ 0.000000] * 0xf1000000..0xff3fe000 : vmalloc & ioremap [ 0.000000] Memory: 3062612K/3118080K available (10732K kernel code, 712K rwdata, 2044K rodata, 276K init, 287K bss, 55468K reserved, 0K cma-reserved, 2331640K highmem) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 > >Christophe > -- > Sincerely yours, > Mike
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c index 3d690be48e84..59a84629d9a0 100644 --- a/arch/powerpc/mm/init_32.c +++ b/arch/powerpc/mm/init_32.c @@ -125,10 +125,10 @@ void __init MMU_init(void) * lowmem_end_addr is initialized below. */ if (memblock.memory.cnt > 1) { -#ifndef CONFIG_WII +#if !defined(CONFIG_WII) && !defined(CONFIG_WIIU) memblock_enforce_memory_limit(memblock.memory.regions[0].size); pr_warn("Only using first contiguous memory region\n"); -#else +#elif defined(CONFIG_WII) wii_memory_fixups(); #endif }
pgtable_32.c:mapin_ram loops over each valid memory range, which means non-contiguous memory just works. Signed-off-by: Ash Logan <ash@heyquark.com> --- arch/powerpc/mm/init_32.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)