Re: [hatari-devel] Hatari freeze on XaAES quit with 030 MMU + FPU + cache emulation

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi Nicolas,

On 26.7.2022 18.17, Eero Tamminen wrote:
> No, it does not report anything.
>
> Hatari just freezes:
> ------------------------
> VDI 0x65/0x00 (v_clsvwk)
> WARNING: xconout stack args not found by skipping return addresses, 
> trying short skipping.
> WARNING: xconout args not found from stack.
> <freeze>
> ------------------------
>
> When I enabled cpu_symbols tracing for EmuTOS, in addition to tracing 
> all OS calls, I saw something fairly weird in the log (attached).

Is there anything else I could try to trace to see what causes the freeze?


> It seems like EmuTOS would proceed after VDI close to panic, halt and 
> reboot, and then continue booting, without *anything* being visible on 
> Hatari screen, or xconout interception working.

Especially this sequence is very odd:
-----------------
_nvram_init:
_panic:
_halt:
_warm_reset:
_cold_reset:
-----------------

halt should loop forever, and warm_reset() should clear cache and jump 
to main(), not continue ignoring all branching:
https://github.com/emutos/emutos/blob/master/bios/panicasm.S


Looking at the trace, MMU setup function is called only after above 
weird sequence, so I do not think EmuTOS messes with that, but could 
Hatari do something weird to MMU mapping tables in some corner case?

And looking later to the trace, why the heck EmuTOS is trying to do DSP 
on emulated 030 MegaST?


Btw. I tried this use-case also under Valgrind, and that did not report 
anything iffy in Hatari's dynamic allocations access (Hatari uses a lot 
of static allocations though).

When I killed Valgrind it reported Hatari to be on DSP_Run() call:
==5083== Process terminating with default action of signal 1 (SIGHUP)
==5083==    at 0x50BEF9: m68k_run_mmu030 (newcpu.c:6453)
==5083==    by 0x507291: m68k_go (newcpu.c:7614)
==5083==    by 0x4704DC: main (main.c:966)
?

	- Eero

PS. GCC AddressSanitizer (defaults) did not find any issues for this 
either, but I pushed fix to unrelated issue it noticed.