Hi Mike,
On Thu, Mar 25, 2021 at 10:46 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote:
On Thu, Mar 25, 2021 at 02:03:25PM +1100, Finn Thain wrote:
Stan has sent me a series of logs from v5.10 and v5.11 showing a
regression apparently caused by the deprecation of CONFIG_DISCONTIGMEM.
This v5.11 kernel build has CONFIG_FLATMEM=y and
CONFIG_FORCE_MAX_ZONEORDER=11 which is now the default. The 5.10 build has
CONFIG_DISCONTIGMEM=y.
This system is a Mac IIci, which has two RAM banks. Bank A has physical
address 0 and bank B has 0x04000000. This model often has two
discontiguous RAM chunks. However, installing 64 MB in bank A does avoid
that.
There is a bootloader issue in play here. The bootloader (Penguin) prefers
to locate the kernel and initrd in the largest bank. Hence it may fail to
choose the lowest bank even when that bank is sufficiently large. When
that happens, Linux is unable to use the RAM in bank A.
Linux has always complained about this situation but now it crashes. This
seems to be a regression in v5.11. Can anyone help debug this?
There was a bug in the definition of ARCH_PFN_OFFSET that's quite probably
causes the crashes when the kernel is located in the second memory bank.
The fix was posted a while ago:
https://lore.kernel.org/linux-m68k/20210228190828.392974-1-angelo@xxxxxxxxxxxxxxxx
Can you check if this helps?
Thank you!
I hadn't realized this applies to classic m68k, too.
One more reason to annotate #else and #endif keywords, to avoid
people guessing wrong...
Greg: This is in linux-next, and still destined for v5.12, I assume?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
