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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

To recap the findings so far:

* Issue is not recent, and could have been there since cache emulation 
started working with MMU

* No warnings with CPU core MMU debug, gcc ASAN or Valgrind

* Happens only with 030 + MMU + FPU + cache emulation

* Triggered after closing all apps in MiNT + XaAES, and quitting XaAES, 
with last OS call being VDI workstation close
  - After which Hatari's xconout vector interception stops working for 
EmuTOS

* Triggered only under EmuTOS, around v1.1.1:
  - After it switched from MFP polling to interrupt driven mode
  - But before VDI workstation memory was fixed to be allocated from 
supervisor accessible memory


I.e. memory access rights handling / change is related to this (VDI wk 
close with its memory being non-supervisor accessible), which makes 
sense when trigger needs MMU + caching.

But can somebody explain how EmuTOS MFP driver interrupt handling, and 
FPU being present could relate to this / are needed for triggering the 
freeze?


Thomas' analysis of the hang on Hatari side:

"When the hang happens, it seems like the emulated code is looping 
through the whole cleared memory, only executing op_0000_35_ff() in 
cpuemu_35.c.

And this never seems to add any cycles anymore, thus Hatari completely 
hangs in the m68k_run_mmu030() loop, without ever generating an 
interrupt and thus not reacting to user input anymore."


My EmuTOS symbol address tracing showed program counter running also 
through EmuTOS code without taking branches.  I assume ROM area could 
not have been cleared, but could it have been mapped somewhere else with 
MMU, so that it all looks fine from the CPU core point of view?

And if TOS is taken out of the picture that way, would that cause Hatari 
to freeze?


Note: I'm not sure how one would verify that with Hatari debugger.  That 
uses physical addresses, not virtual MMU mapped ones, so maybe it would 
still see normal ROM content, not what the CPU would run for that address?


	- Eero