Eero,
that issue (kernel running from TT-RAM) was fixed quite a few years ago
(but maybe not in 2013), in the sense that ST-RAM could be used for
drivers (SCSI, atafb). Using ST-RAM as normal VM should have been made a
lot easier by changing to memblock, but AFAIR there are still some bits
missing.
RAM must be listed in bootinfo with the chunk holding the kernel first,
_not_ in ascending address order, so that second option is expected to
crash.
This isn't related to the current issue for all I can see.
Cheers,
Michael
Am 27.02.2023 um 22:41 schrieb Eero Tamminen:
Hi,
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
the issue.
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.
https://lists.debian.org/debian-68k/2022/09/msg00047.html
https://lists.debian.org/debian-68k/2022/09/msg00051.html
https://lists.debian.org/debian-68k/2022/09/msg00055.html
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)
- Eero
PS. For people familiar only with Amiga terminology, ST-RAM = chip RAM,
TT-RAM = fast RAM.
