|Re: [hatari-devel] m68k Linux under Hatari|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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 , not Hatari related one, and for which
I do have a workaround:
=> I'm testing Busybox "hostid" command instead.
 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:
- 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. :-/