Re: [hatari-devel] m68k Linux under Hatari

[ Thread Index | Date Index | More 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 [1], not Hatari related one, and for which
I do have a workaround:

=> 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

Mail converted by MHonArc 2.6.19+