Re: [hatari-devel] Hatari freeze on XaAES quit with 030 MMU + FPU + cache emulation |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 24.7.2022 21.12, Nicolas Pomarède wrote:
Le 10/07/2022 à 12:11, Eero Tamminen a écrit :
Here are slightly corrected / updated repro instructions, with latest
MiNT snapshot, as older snapshot is not available any more.
I don't have time at the moment to check all this, but can you try this
in cpu/newcpu.c :
- change "#define VALIDATE_68030_DATACACHE 0" to "1" instead
- around line 9853, uncomment this "//#define
WINUAE_FOR_HATARI_DEBUG_CACHE"
this will check that each time a data is read from cache, then the
content in RAM is the same ; if some mismatches are reported, it means
there's sthg buggy in the cache code.
Then run your case again and see if any cache messages are displayed
when things go wrong.
With above 2 lines changed (or just the first one), EmuTOS v1.1.1 does
not even boot.
Just having 030 CPU is then enough for EmuTOS boot to end in:
-------------------------------------
<EmuTOS boot screen>
....
Panic: Bus Error
fw=b008 ir=0000 ssr=0341
addr=0000059c sr=0300 pc=00e64b7a
D0-3: 00000000 00000000 00000000 00000000
D4-7: 00000000 00000000 00000000 00000000
A0-3: 00000000 00000000 00000000 00000000
A4-7: 00000000 003da6f8 003da6c6 00007e08
USP: 003da6f8
basepage=00014970
text=00e64b78 data=00000000 bss=00000000
-------------------------------------
I.e. I do not need to enable even MMU or FPU.
Even when 030 cache emulation is disabled with "--cpu-exact off", it
still crashes!
Same issue with EmuTOS v1.2 Git version.
TOS 3.06 dies to double bus error on:
WARN : Bus Error reading at address $68, PC=$e013ae addr_e3=e013ae
op_e3=42a7
TOS 4.04 dies to double bus error on:
WARN : Bus Error reading at address $59c, PC=$e01174 addr_e3=e01174
op_e3=42a7
Only TOS v2.06 on 030 ST, boots up fine with that change.
=> That validation code in Hatari seems broken, as instead of validating
emulation, it changes how things are emulated.
- Eero
PS. I tried also doing clean build, Debug build instead of
RelWithDebInfo, and build with small mem option disabled, but those did
not change anything.