| [hatari-devel] Re: [Emutos-devel] Hatari reset loop during EmuTOS automated testing |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: emutos-devel@xxxxxxxxxxxxxxxxxxxxx
- Subject: [hatari-devel] Re: [Emutos-devel] Hatari reset loop during EmuTOS automated testing
- From: Christian Zietz <czietz@xxxxxxx>
- Date: Fri, 9 Apr 2021 19:42:50 +0200
- Cc: Hatari Development <hatari-devel@xxxxxxxxxxxxxxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1617990171; bh=eZ72AKOQ03gjzjNA5JWEh6KGy3MljbMjysk3O7Tt1AE=; h=X-UI-Sender-Class:To:References:Cc:From:Subject:Date:In-Reply-To; b=lUYMz5TPIPQoNhPhStmxT7dIAOlnRUSfPpfu1XOTawejnnEKwyq0EuekDbPv3oiXL i2w5Za64vrBVrAWwwA7Ij4t0BrtUjRN9s64V0dUtRTSmPYfbYdmbbUDOLTXmPSDGXj 6vN3lj84/KtmzLtLiN75kc2g95MOOcOrqf9jPkxw=
Roger Burrows schrieb:
For now, I'm going to disable the TT test. I don't want to hold up EmuTOS
development for an obscure Hatari problem.
I have a fix for the TT test. I will push it later.
Thanks to the Google Compute Engine, I was able to quickly spin up a VM
with Ubuntu 18.04 to test. Here is what I found:
1. The reason for the reset loop. EmuTOS goes through a reset due to an
apparent change of monitor type. Even if Hatari 2.1.0 is configured for
an color monitor, EmuTOS detects a *monochrome* one during the boot
process of the emulated TT. Later, it correctly detects a color monitor
and resets. This repeats until the test times out.
2. Why I could not reproduce it under Windows. Hatari was using my
config file (in my user directory), which is set for a monochrome
monitor. Therefore, the monitor detection at boot and the subsequent
checks yield the same result. => No reset. I can reproduce it on my
(Windows) machine, too, when configuring a color monitor.
3. Why the initial detection is wrong and why this particular commit
broke it. I cannot explain that. Note that the monitor type is detected
by reading the state of one of the MFP's pins via the GPIP register. But
tracing 'mfp_read' shows that the wrong monitor detection during EmuTOS
boot does not even hit the MFP code in Hatari 2.1.0. I can only assume
that a cached value is used in error.
I think we must conclude that this is a bug in the undoubtedly ancient
Hatari version we currently use in our GitHub Actions build. It is fixed
in Hatari 2.2.x. (I tested that after I knew how to reproduce the issue
in the first place, of course.)
Fortunately, as a short term fix (that I was referring to above) we can
configure the test to use a monochrome monitor. I already confirmed that
this works in my fork of EmuTOS on GitHub.
As a mid-term solution I shall see that we switch to a newer Ubuntu VM
for our builds. E.g., Ubuntu Focal LTS includes Hatari 2.2.1. But that
will require careful testing.
Regards
Christian
--
Christian Zietz - CHZ-Soft - czietz@xxxxxxx
WWW: https://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA