Hi,
On 16.3.2024 19.11, Eero Tamminen wrote:
On 16.3.2024 17.03, Nicolas Pomarède wrote:
but in src/m68000.c you can add at line 396
changed_prefs.cpu_data_cache = false
to force data cache off in all cases ; then if you can test again,
this could tell if problem is in cache or not (if it doesn't works
with cache off, it doesn't mean there's no problem in cache, but at
least it narrows the parts to look at first)
CPU exact & compatible options have no effect on this bug, only
whether CPU cache is enabled (panic/freeze, due to memory not being at
expected address) or not (everything works, although there are lot of
DEBUG log messages [1]).
Btw. enabling "VALIDATE_68040_DATACACHE" in newcpu.c did not show
anything before the panic.
As panic happens on kernel's ST-RAM address validation, it's very early
in boot. At the point 681304 instructions have been executed from 4224
distinct addresses, with 18609 i-cache misses.