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,

Here are slightly corrected / updated repro instructions, with latest MiNT snapshot, as older snapshot is not available any more.

I've also updated compatibility doc to latest findings.


Setup:

1. Download latest FreeMiNT + XaAES snapshot:
wget https://tho-otto.de/snapshots/freemint/bootable/freemint-1-19-7f0af8d0-02060-tt_falcon_clones.zip

2. Add tmp dir for it:
   rm -rf mint-tmp && mkdir mint-tmp && cd mint-tmp

3. Extract it there:
   unzip ../freemint*.zip

4. Remove SCC drivers to avoid MiNT startup freeze:
   rm mint/*/*/scc.xdd

5. Back to upper dir to run test-case:
   cd ..


Test-case:

1. Make 24MB HD image out of FreeMiNT snapshot dir:
   rm -rf mint.st
   atari-hd-image 24 mint.st MiNT mint-tmp/

2. Boot that with EmuTOS v1.1.x + 030 MMU + FPU + cache emulation, e.g:
hatari --tos etos1024k.img -s 14 --machine tt --mmu on --cpu-exact on --scsi mint.st
or:
hatari --tos etos1024k.img -s 14 --machine falcon --fpu 68882 --mmu on --cpu-exact on --ide-master mint.st
or:
hatari -m --tos etos1024k.img -s 14 --machine megast --fpu 68882 --cpulevel 3 --cpuclock 16 --mmu on --cpu-exact on --acsi mint.st

3. Switch to XaAES from application "Desk" -> "Clients" menu

4. In XaAES, click on "Process" -> "Quit all Apps" menu item

5. Then click on "Process" -> "Quit XaAES"

=> Hatari freezes


Note-1: because Hatari needs to be killed when it freezes, the image contents are corrupted and it needs to be re-created to run the test-case again.

Note-2: Steps 3-4 can normally be replaced by just quitting the application from "File" -> "Quit".


With working (newer and older) EmuTOS versions, quitting XaAES causes everything to be restarted i.e. re-doing VDI workstation allocations. With EmuTOS v1.1.x, this would mean hitting the EmuTOS VDI alloc MMU protection bits issue, fixed in:
https://github.com/emutos/emutos/commit/b245f3cfac7bdb146401a642bbf49ed4de1283cd


If I enable console output (with "--trace os_base")...

With working EmuTOS version, I get this in console after selecting XaAES Quit:
-----------------------------------
wake loader: 1C41A6;shutdown=8007
AESSYS kthread exited - shutdown = 8007(Quit XaAES).
XaAES loader: KM_FREE
XaAES loader: KM_FREE failed trying: ''..
XaAES loader: pid=1.
XaAES loader starting...
u:/c/mint/1-19-7f0/xaaes/'
Load kernel module: 'xaaes.km'
pid   1 (xaloader): run_km(xaaes.km) ok (bp 0x144160)!
pid   1 (xaloader): run_km: run=0x144260
XaAES v1.6.4 Beta (m68020-060, Jul 5 2022 18:05:02) (MultiTasking AES for MiNT)
Part of freemint (https://freemint.github.io/).
home_path: 'U:\c\MINT\1-19-7F0\XAAES\'
both moose_w.adi and moose.adi found (better choose one)

pid   8 (AESSYS): parse_cnf: can't open U:\c\MINT\1-19-7F0\XAAES\xaaes.inf
-----------------------------------

And with EmuTOS v1.1.1, I get:
-----------------------------------
WARNING: xconout stack args not found by skipping return addresses, trying short skipping.
WARNING: xconout args not found from stack.
-----------------------------------

If I enable also tracing of all OS calls, there's just this before the xcounout warnings:
-----------------------------------
VDI 0x65/0x00 (v_clsvwk)
-----------------------------------

=> maybe the issue triggers on VDI alloc free?

I have still no idea how MFP interrupts and cache emulation relate to this.


	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/