On 27.2.2023 9.19, Michael Schmitz wrote:
Am 27.02.2023 um 18:55 schrieb Finn Thain:
On Mon, 27 Feb 2023, Michael Schmitz wrote:
Bisected to commit 376e3fdecb0dcae2 ("m68k: Enable memtest
functionality") in v5.17-rc1. Reverting that on top of latest fixes
Yes, I'm sorry to say that was the only likely candidate. Can't see why
though - are Macs all configured to have RAM start at address zero, and
possibly contiguous, Finn?
I don't really understand your question. This was not a Mac patch. The
issue seems to be about the locations initrd_start and initrd_end in
relation to the various memory segments (?)
I didn't realize that - thanks for pointing this out.
This seems to be the same bug that was raised about 6 months ago... I had
thought it was a bootloader bug but I'm out of my depth here.
I had forgotten all about that one... Thanks for jogging my memory!
In this case though, the bug happens when the ramdisk is loaded in the
lowest address memory chunk, at least at a lower address than the one
the kernel runs from.
I'm wondering whether this old Atari side boot issue is related at all...
When adding Linux bootinfo support to Hatari emulator (from Aranym
emulator) few years ago, I noticed that:
"Linux barfs at ST-RAM memory range given after TT-RAM. However, if
kernel is loaded to TT-RAM and ST-RAM range is given before TT-RAM
range, kernel crashes."
=> Only working config was Linux being loaded to ST-RAM, TT-RAM being
given only after that in bootinfo, and initrd ramdisk after kernel.
Based on mails in archive, this seemed to have been a known Linux/Atari
issue already in 2013.
The crashes in the above thread were all from boots where the initrd got
loaded at the end of the memory chunk the kernel runs from.
Time to try using copy_from_kernel_nofault() to copy the ramdisk into
its final location? (just kidding)
PS. For people familiar only with Amiga terminology, ST-RAM = chip RAM,
TT-RAM = fast RAM.