| Re: [hatari-devel] Hatari freeze on XaAES quit with TT + MMU + 24-bit emulation |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 6.7.2022 23.31, Nicolas Pomarède wrote:
Le 06/07/2022 à 22:19, Nicolas Pomarède a écrit :
But when the hang happens, it seems like the emulated code is looping
through the whole cleared memory, only executing op_0000_35_ff() in
cpuemu_35.c. And this never seems to add any cycles anymore, thus Hatari
completely hangs in the m68k_run_mmu030() loop, without ever
generating an
interrupt and thus not reacting to user input anymore...
I had the feeling the hang happened on the above loop, but I will let
hatari runs for longer until I read the point you mention (where input
is not processed anymore)
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", "Reboot" or "Shutdown"
7. XaAES: "Process" -> "Quit XaAES"
no lock here when running :
./hatari --tos etos1024k.img --machine tt -s 14 --fast-boot on --mmu on
--log-level debug --cpu-exact on --addr24 on
it boots to gem desktop
Do I really need to use XaAES to see this freeze or can it be seen with
just emutos 1.1.1 ?
(Emu)TOS itself does not do that much, it mostly offers services for
applications. Same applies also to MiNT. I.e. to provoke certain
things one needs to run applications which do OS calls etc.
Note: This issue does not happen with EmuTOS v1.0 512k version either.
It only happens with EmuTOS v1.1.x (512k / 1024k) version.
Btw. While disabling prefetch with "--compatible off" did not change
anything, there's another problem when disabling cycle-exact mode with
MMU enabled ("--cycle-exact off --mmu on"): Teradesk does not start from
the MiNT image. This happens regardless of 24-/32-bit setting.
Although cycle-exact + 24-bit mode are default for TT (when TT-RAM is
not enable), and Hatari v2.4 binaries are going to ship with EmuTOS
v1.1.1, I do not think this freeze needs to block release because:
* It's not (recent) regression as this happens also with Hatari v2.3.1
* MiNT running under 24-bit mode (= no TT-RAM) with MMU [1] is fairly
rare Hatari usage scenario
* EmuTOS v1.2 will be released soon, so users can upgrade EmuTOS [2]
[1] Maybe MiNT changes MMU tables when XaAES quits?
[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
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