Re: [hatari-devel] m68k Linux under Hatari

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 2/27/20 11:13 AM, Nicolas Pomarède wrote:
> Le 27/02/2020 à 00:26, Eero Tamminen a écrit :
> > On 2/24/20 12:45 PM, Nicolas Pomarède wrote:
> hard to tell what's going on with just this kernel dump.
>
> could you try this :
>
>   - in a console under linux/hatari, type "echo t > /proc/sysrq-trigger" 
> (don't press enter)
>   - at this point, save a memory snapshot

That particular case was the only one that was
verified to happen also on real HW i.e. be Linux
issue [1], not Hatari related one, and for which
I do have a workaround:
https://git.tuxfamily.org/hatari/hatari.git/tree/tools/linux/sysrq-tasklist-error.patch

=> I'm testing Busybox "hostid" command instead.


[1] kernel bus_error030() function still doesn't
seem to respect kernel asking page faults to be disable in 
kernel_probe_read() in Linux v5.4.

It's possible that it's impacting some of the
issues I've listed, but at least few of them were
tested not to happen on real HW (030 Mac).


>   - restart hatari with --memstate XXXX and --trace all,-int,-cpuregs 
> (redirect stderr to a file)

Note that I don't need to restart Hatari to change
trace flags, I can do it from the debugger prompt:
	trace all,-int,-cpu_regs


>   - press 'enter' to validate the "echo t > /proc/sysrq-trigger" command 
> and stop hatari when the crash happens.
>
> This way you should get a a more verbose trace with all the context.

That's way too much output for me. There's so much
stuff happening at Linux user-space program start
up with normal libc init, all the kernel calls
etc, that there's no way I can find out where
something goes wrong from a trace like that. :-/


	- Eero