On Thu, 6 Dec 2018, Eero Tamminen wrote:
> On 12/6/18 1:10 AM, Finn Thain wrote:
> > On Tue, 4 Dec 2018, John Paul Adrian Glaubitz wrote:
> > > On 12/3/18 8:13 AM, Finn Thain wrote:
> > > > The problem turns out to be dash. I got things working again by
> > > > replacing /bin/sh and /bin/dash with symlinks to bash and then
> > > > running 'apt --fix-broken install' to finish the upgrade.
> > >
> > > Thanks for the heads-up! I just ran into this problem with
> > > qemu-system but not with qemu-user. I wonder whether it's related to
> > > [1].
> > >
> >
> > It happens in aranym too. I tried strace,
> >
> > execve("/root/dash", ["/root/dash", "-c", "/bin/echo"], ["PWD=/",
> > "HOME=/", "BOOT_IMAGE=vmlinux", "TERM=linux", "SHLVL=1",
> > "_=/usr/bin/strace"]) = 0
> >
> > [...]
> >
> > get_thread_area() = 0xc0022490
> > get_thread_area() = 0xc0022490
> > get_thread_area() = 0xc0022490
> > get_thread_area() = 0xc0022490
> > get_thread_area() = 0xc0022490
> > get_thread_area() = 0xc0022490
> > get_thread_area() = 0xc0022490
> > clone(child_stack=NULL,
> > flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=NULL) =
> > 415
> > wait4(-1,
> > 0xefdaba3e, 0, NULL) = -1 ECHILD (No child processes)
> > --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=415, si_uid=0,
> > si_status=0, si_utime=0, si_stime=2} ---
> > rt_sigreturn({mask=[]}) = -1 ECHILD (No child processes)
> > get_thread_area() = 0xc0022490
> > wait4(-1, 0xefdaba3e, 0, NULL) = -1 ECHILD (No child processes)
> > get_thread_area() = 0xc0022490
> > wait4(-1, 0xefdaba3e, 0, NULL) = -1 ECHILD (No child processes)
> > get_thread_area() = 0xc0022490
> > wait4(-1, 0xefdaba3e, 0, NULL) = -1 ECHILD (No child processes)
> > get_thread_area() = 0xc0022490
> > wait4(-1, 0xefdaba3e, 0, NULL) = -1 ECHILD (No child processes)
> >
> > The last two lines loop indefinitely, and dash never teminates, even
> > though the child process has terminated already (SIGCHLD can be seen
> > above).
>
> With Hatari (68000-68060 Atari) emulator, you should be able profile
> what kernel is doing at CPU instruction level:
> https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-file/tip/doc/manual.html#Profiler
>
I suspect qemu-user avoids the problem by intercepting syscalls (implying
a 68k kernel bug).
And if a kernel bug was somehow exposed by recent changes to dash, I'd
expect hatari would behave the same as aranym and qemu-system.
> I don't think anybody's tried running full Linux with Hatari yet (only
> no-MMU ones), but it shares CPU core with WinUAE, which has been tested
> with NetBSD & Linux, so Linux "should" work fine e.g. with Hatari's
> Atari TT emulation.
>
> I can help with anything Hatari related (first thing, change crypto from
> sha e.g. to md5, otherwise logging in takes ages, even if cycle- exact
> emulation is disabled. Higher emulation accuracy and no JIT, makes
> Hatari *much* slower than Aranym).
>
> Note: for 030/040/060 MMU + prefetch + i/d-cache emulation, you should
> build Mercurial version of Hatari:
> hg clone http://hg.tuxfamily.org/mercurialroot/hatari/hatari
>
> (Latest 2.1 Hatari release emulates either MMU or cache, not both at
> the same time, is quite old and its MMU emulation had several bugs.
> Aranym emulates only 040, and AFAIK doesn't have any cache emulation.)
>
Sounds very promising!
--
>
> - Eero
>
>
