Re: [hatari-devel] Linux user-space crashes (was: SCU/VME register access)

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 14.6.2024 19.02, Nicolas Pomarède wrote:
> Le 14/06/2024 à 11:13, Eero Tamminen a écrit :
> > Btw. that's not the only problem.
> >
> > Hatari emulation has also some issues with MMU + data-cache emulation, 
> > which according to Toni, do not happen under WinUAE for m68k-linux on 
> > Amiga.
> >
> > User-space programs crash when data-cache emulation is enabled (e.g. 
> > init, which causes kernel panic).
> >
> > It would be nice to verify that it really does not happen on real HW, 
> > either with Falcon, or after Nicolas fixes SCU emulation, on TT.  That 
> > will require use of a root file system though, so it's something that 
> > could be done after other Linux kernel boot issues (which are easier 
> > to debug) have been fixed.
>
> When I run the linux kernel you sent with
>
> --ide-master klibc-rootfs.img
>
> linux boot to busy box and I can run 'ls' for example

This image contains several (tiny) tools in /bin/, which are statically 
linked against (tiny) kernel libc (klibc).

Normally these are used only on kernel initrd.


> but when I run with the other image
>
> --ide-master bb-rootfs.img
> > it also boots to busy box, but running 'ls' or any command gives a
> 'segmentation fault'

This image contains single multi-call /usr/bin/busybox binary (+ lots of 
tool symlinks to it), that is statically linked against normal (huge) 
Debian m68k Glibc.

Normally _statically_ linked BusyBox version is used on small install 
medias like floppies.


> do you know why ? what's the difference between these 2 img ?

Both images contain tools binaries installed from packages in Debian 
m68k ports repository.

But the binaries themselves are different, and (statically) linked to a 
different C-library.

While BusyBox itself tries to do minimal amount of things (to keep 
small), Glibc can do _a lot_, and I think issue could be with the extra 
things Glibc does compared to klibc.


> Is that what you mean with "User-space programs crash when data-cache 
> emulation is enabled" or is this another scenario ?

Yes, it's that scenario.  The exact issues have changed from one Hatari 
version to another, but the Busybox/Glibc one has never behaved 
correctly when data-cache is enabled (with MMU, without which Linux does 
not work).

It could be something related to switching between kernel & user-space 
on each syscall (of which Glibc does a lot), and everything that happens 
then:
- MMU mapping changes
- register content restoration
(- exceptions)

Because all Busybox tools do not crash, mostly just things that deal 
with HW IO like disk, it could be Hatari bugs in its IO cache flushing.


	- Eero