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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 26/07/2022 à 18:37, Eero Tamminen a écrit :

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

Maybe, see my other mail for adding more MMU logs.

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

This is definitely wrong (since a long time in Hatari) : for example 
m68k_run_mmu030 () does this :

  if (bDspEnabled) {
        DSP_Run(2 * cpu_cycles * 2 / CYCLE_UNIT);
  }

so, as soon as DSP is enabled in the GUI or with some --options, this 
calls DSP_Enable() in falcon/dsp.c, which sets bDspEnabled=true , even 
if machine is not a falcon and has no DSP at all (even an STF will 
report bDspEnabled=true)  :(((

we should at least have this change :

-- a/src/falcon/dsp.c
+++ b/src/falcon/dsp.c
@@ -191,8 +191,11 @@ void DSP_Reset(void)
 void DSP_Enable(void)
 {
 #if ENABLE_DSP_EMU
-       bDspEnabled = true;
-       DSP_CyclesGlobalClockCounter = CyclesGlobalClockCounter;
+       if ( Config_IsMachineFalcon() )
+       {
+               bDspEnabled = true;
+               DSP_CyclesGlobalClockCounter = CyclesGlobalClockCounter;
+       }
 #endif
 }

Can you try ? it should not call DSP_Run() in TT mode, maybe improving 
your tests  (to be complete, we should do the same in DSP_Init and 
DSP_UnInit, but aprat from calling un-needed DSP functions when not in 
falcon mode, it should not give problems)

> 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).