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