Hi,
On 8.2.2023 19.39, Stan Johnson wrote:
The stack smashing appears to be intermittent. And it doesn't show up
while booting the kernel; it only shows up while sysvinit scripts are
running (I haven't tested using systemd, since that would be too painful
on any 68030 slower than about 40 MHz). It takes too long to boot slow
systems using Debian's kernel to run repeated tests, and QEMU only
emulates 68040, so it appears to be necessary to test on real hardware.
It's not my goal to get my config files closer to Debian's, anyway. My
goal is to have the fewest number of config files for different groups
of systems.
If anyone knows of a 68030 emulator (maybe Basilisk?) that can boot
Linux, then I might be able to use that for faster testing.
On quick search I was not able to find out whether Basilisk II (or mini
vMac) emulate both 030 MMU and CPU i/d-cache. If they don't, they may
not be accurate enough to find issues like this.
In case the issue is only 030, not Mac specific, both WinUAE (Amiga) and
Hatari (Atari) emulators support 68030 + MMU + cache emulation, and can
boot Linux.
Hatari CPU core is based on one from WinUAE.)
Apparently WinUAE has not had problems running Linux, but in Hatari,
enabling 030 _cache_ emulation breaks Linux boot when it reaches user
space (kernel boot works fine).
I'm not sure whether latter is related to the issue you are seeing on Mac.
(There are some differences e.g. in how Amiga and Atari handle CPU
exceptions and how MMU is used, which may explain differences in
behavior. I have no idea whether Mac is closer to Amiga or Atari in
this respect.)
For details on using m68k Linux with Hatari, see:
https://hatari.tuxfamily.org/doc/m68k-linux.txt
- Eero
PS. Debugger in Hatari emulator can provide you with backtraces for
Linux kernel side, and profile where kernel time goes.
For a full boot, callgraphs will be so large that you'll probably need
to throw away 99% fo the data though, to make them readable. For
details, see:
https://hatari.tuxfamily.org/doc/debugger.html#Profiling
