| Re: [hatari-devel] Hatari reset loop during EmuTOS automated testing (was: Interrupt-driven I/O for TT MFP) |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 09/04/2021 à 12:42, Christian Zietz a écrit :
Hi,
cross-posting to EmuTOS and Hatari lists, as this is really strange: So,
EmuTOS automated tests using a TT emulated by Hatari broke after this
commit:
https://github.com/emutos/emutos/commit/8e40b049d8eb0f77012630f8898488ba675a45d4
... which is /not/ the MFP interrupt commit, BTW.
On my fork on GitHub I enabled debug output from Hatari. See attached
log file. To me, this looks as if Hatari is stuck in a reset loop until
the maximum number of VBLs is reached. EmuTOS GitHub Actions build is
using Hatari 2.1.0 (from the respective Ubuntu package). However, with
Hatari 2.1.0 for Windows (from the official download page), I cannot
reproduce the issue: the test passes fine there.
To me, this looks as if there is a bug, not in EmuTOS, but in the Ubuntu
(or Linux) version of Hatari 2.1.0. Any idea how to proceed? Since I can
currently only reproduce this on GitHub Actions, I cannot test
interactively. Is there anyone that has access to a machine with Ubuntu
Bionic and could confirm that the EmuTOS tests ("make test") fail there?
Regards
Christian
Hi
Having different result depending on the OS/version looks like some out
of bound memory accesses that exists since some time but maybe got only
triggered now due to reset_mfp_regs() being shorter than it was before
and different code space.
Does it only fail my the 1024 KB emutos version ? not with the shorter
ones ?
Do you have a way to run with "--trace all,-cpu_regs,-int" to get the
disasm outpout of what is happening and to see where it is looping ?
Nicolas
PS : I'm not subscribed to emutos-devel, so my answer won't reach them.
Nicolas
*Gesendet:* Freitag, 09. April 2021 um 10:25 Uhr
*Von:* "Christian Zietz" <czietz@xxxxxxx>
*An:* emutos-devel@xxxxxxxxxxxxxxxxxxxxx
*Betreff:* Re: [Emutos-devel] Interrupt-driven I/O for TT MFP
Roger Burrows schrieb:
> I've finished adding support for interrupt-driven I/O on the TT MFP,
so I'm
> going to stop messing with serport.c and friends for now.
Unfortunately, snapshot builds are currently broken. This is because the
"cookie" test on the TT fails. I've rerun the GitHub Actions build, in
(the unlikely) case this was a transient error (e.g. race condition);
but it isn't.
I cannot reproduce this failure locally: tests work with Hatari 2.2.1
[1]. GitHub Actions (or rather the chosen Ubuntu container) uses an
older Hatari version. I have to postpone further investigations to
later, though.
Regards
Christian
[1] On Hatari 2.3.1 the recently fixed issue with 1024k ROMs prevents
the test from passing.
--
Christian Zietz - CHZ-Soft - czietz@xxxxxxx
WWW: https://www.chzsoft.de/ <https://www.chzsoft.de/>
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA
_______________________________________________
Emutos-devel mailing list
Emutos-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/emutos-devel
<https://lists.sourceforge.net/lists/listinfo/emutos-devel>