FYI I can reproduce using EmuTOS 1.1.1 on my Mac. I also only see it with MMU enabled and 24 addressing.
Hi,
On 26.6.2022 9.27, Thomas Huth wrote:
> Am Fri, 24 Jun 2022 17:32:26 +0300
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
>> Hatari hard-freezes with following:
> [...]
>> 7. In XaAES, click on "Process" -> "Quit all Apps" menu item
>>
>> 8. Then click on "Process" -> "Quit XaAES"
>>
>> => After second or two, Hatari freezes completely.
>
> I cannot reproduce the issue - for me, XaAES simply gets restarted in that
> case. Which version of EmuTOS are you using?
Freeze happens with EmuTOS v1.1.1 (which is going to be shipped with
Hatari), but not with the latest Git version of EmuTOS.
Can you reproduce it with EmuTOS v1.1.1?
>> NOTE-2: Hatari freeze does not happen if I disable MMU, use 32-bit
>> addressing, use Falcon, or skip step 7).
>
> Ok, then I think this should not block the release, since the TT is
> supposed to be a 32-bit machine and 24-bit is rather an exotic setting here.
Currently Hatari defaults to 24-bit addressing also on TT, and switches
to 32-bit addressing only if TT-RAM is used.
But my main worry is that Hatari freeze is not specific to this
particular configuration, but some more generic issue with Hatari MMU
handling. Until it is root-caused [1], one cannot really say. :-/
Because Laurent apparently has MMU enabled by default and has not
reported freezes, and because I did not see the freeze in my other
testing, it seems at least rare enough that it would not block release.
- Eero
[1] I'm missing time and competence to debug CPU core myself though,
besides providing the backtrace and test-case.