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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

I finished bisecting EmuTOS changes for this.

On 9.7.2022 12.28, Eero Tamminen wrote:
> I found slightly shorter way to trigger the freeze after setup (steps 
> 1-4) and starting Hatari (step 5).
>
> Instead of steps 6-8 (switch to XaAES client, quit all AES apps, quit 
> XaAES), one can do:
>
> 6. Teradesk: "File" -> "Quit/Shutdown" -> "Quit" (or "Reboot" or "Shutdown")
>
> 7. XaAES: "Process" -> "Quit XaAES"

With some EmuTOS version only TOSWin2 gets started, not Teradesk.  Then 
step 6) can be replaced with:

6. TOSWin2: "File" -> "Quit"


NOTE: This issue is neither 24-bit addressing, nor TT specific after all.

I was able to trigger Hatari freeze also with 32-bit addressing on TT:
hatari --tos etos1024k.img -s 14 --machine tt --mmu on --addr24 off 
--cpu-exact on --ide-master mint.st

And under Falcon emulation, after adding FPU emulation:
hatari --tos etos1024k.img -s 14 --machine falcon  --fpu 68882 --dsp off 
--mmu on --addr24 on --cpu-exact on --ide-master mint.st

Even with MegaST/e:
hatari -m -s 14 --machine megast --cpulevel 3 --cpuclock 16 --fpu 68882 
--mmu on --cpu-exact on --acsi mint.st


I was not able to trigger it when using 040 or 060 (or 030@8Mhz).

=> Updated the title accordingly.


[...]
 > [2] I'll bisect which changes in EmuTOS triggered this in v1.1.1, and
> later fixed it for Git version.  That should give more clues for the cause

EmuTOS v1.1 change triggering Hatari freezing on XaAES quit, is 
switching from MFP polling to interrupt driven mode:
https://github.com/emutos/emutos/commit/f18beeca6b4675335b19e460fea0d34395f18d9d

EmuTOS git version change after which Hatari does not freeze on XaAES 
quit any more, is (fix) allocating VDI workstation memory from 
supervisor accessible memory:
https://github.com/emutos/emutos/commit/b245f3cfac7bdb146401a642bbf49ed4de1283cd


=> maybe Hatari does not handle MFP interrupts properly under MMU 
emulation when cache is emulated, if there's an MMU exception? (or FPU one?)


> Could somebody try Hatari versions older than v2.3.1 to see whether this 
> issue has been there since Hatari got cycle-exact MMU support i.e. MMU 
> with 030 cache emulation in v2.1.0?


	- Eero