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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 26.7.2022 19.37, Nicolas Pomarède wrote:
> Le 26/07/2022 à 17:17, Eero Tamminen a écrit :
> > Maybe the reason for CPU core freeze is some weird MMU setup done by 
> > EmuTOS v1.1.1 that had corrupted its state?
>
> At the top of cpu/mmu_common.h, you can change all/some of these lines 
> to "1" (depending on the number of logs you get which can be big)
>
> #define MMUDEBUG 0
> #define MMUINSDEBUG 0
> #define MMUDEBUGMISC 0
>
> Then you can see if anything happens regarding MMU just before the freeze

Nothing happens, i.e. whatever causes the Hatari freeze, satisfies 
WinUAE internal logic.

After enabling the first one, I just get gcc build warnings:
----------------------------------------------
src/cpu/cpummu030.c: In function ‘dump_opcode’:
src/cpu/cpummu030.c:1760:3: warning: enumeration value ‘sz_single’ not 
handled in switch [-Wswitch]
 1760 |   switch (dp->size)
      |   ^~~~~~
src/cpu/cpummu030.c:1760:3: warning: enumeration value ‘sz_double’ not 
handled in switch [-Wswitch]
src/cpu/cpummu030.c:1760:3: warning: enumeration value ‘sz_extended’ not 
handled in switch [-Wswitch]
src/cpu/cpummu030.c:1760:3: warning: enumeration value ‘sz_packed’ not 
handled in switch [-Wswitch]
----------------------------------------------

At first I could not even trigger the Hatari freeze any more, even when 
disabling these MMU debug options, but then the freezes started 
happening again.

I found no pattern what could explain that, but it seems that the issue 
is not 100% reproducible after all. :-/


	- Eero