Bug#1131809: dracut: ppc64el autopkgtest are flaky and take 7 hours per run

Hi,

> 2026=E5=B9=B47=E6=9C=8822=E6=97=A5 06:51=EF=BC=8CMiao Wang =
<[email protected]> =E5=86=99=E9=81=93=EF=BC=9A
>=20
>>=20
>> 2026=E5=B9=B47=E6=9C=8822=E6=97=A5 06:39=EF=BC=8CBenjamin Drung =
<[email protected]> =E5=86=99=E9=81=93=EF=BC=9A
>>=20
>> On Thu, 2026-07-16 at 17:33 +0800, Miao Wang wrote:
>>> On Tue, 30 Jun 2026 20:18:40 +0200 Paul Gevers <[email protected]> =
wrote:
>>>> Hi,
>>>>=20
>>>> On 29-06-2026 13:12, Benjamin Drung wrote:
>>>>>> For now, I've added dracut/loong64 to the reject_list to save =
resources
>>>>>> (the test get triggered often).
>>>>>=20
>>>>> The long execution time is caused by the individual tests running =
into
>>>>> the test-configured timeout. I just uploaded dracut 110-4 which =
contains
>>>>> a patch to use edk2 firmware for loong64 tests. This should =
resolve
>>>>> running into the timeouts.
>>>>=20
>>>>=20
>>>> I've scheduled a run manually. Let's see how it fares.
>>>=20
>>> Hi, I just noticed you have discussed the autopkgtest failures on =
loong64
>>> here. At first the failure was because the UEFI firmware was not =
used and
>>> the Linux kernel relies on the ACPI table provided by the UEFI =
firmware
>>> to work correctly. Later the failure is because the race condition =
in qemu.
>>> I just sent patches to qemu to fix this [1].
>>=20
>> Thank you. Looking at the loong64 test logs [1] shows an execution =
time
>> between found and eight hours. The test for 111-6 has this result:
>>=20
>> 16179s lsinitrd             PASS (superficial)
>> 16179s 10-basic             PASS
>> 16179s 13-sysroot           PASS
>> 16179s 14-hooks             PASS
>> 16179s 40-systemd           PASS
>> 16179s 42-systemd-initrd    PASS
>> 16179s 43-kernel-install    PASS
>> 16179s 80-getarg            PASS
>> 16179s 81-skipcpio          PASS
>> 16179s 11-usr-mount         PASS
>> 16179s 20-storage           PASS
>> 16179s 26-enc-raid-lvm      PASS
>> 16179s 21-overlayfs         FAIL non-zero exit status 124
>> 16179s 30-dmsquash          FAIL non-zero exit status 1
>> 16179s 31-livenet           PASS
>> 16179s 41-full-systemd      PASS
>> 16179s 44-drivers           PASS
>> 16179s 45-systemd-import    PASS
>> 16179s 46-systemd-sysext    PASS
>> 16179s 50-network           PASS
>> 16179s 60-nfs               FAIL non-zero exit status 124
>> 16179s 70-iscsi             FAIL non-zero exit status 124
>> 16179s 71-iscsi-multi       PASS
>> 16179s 72-nbd               PASS
>>=20
>> 21-overlayfs and 30-dmsquash wich should be fixed by your qemu fix I
>> assume.
>>=20
>> 60-nfs and 70-iscsi show multiple "PROGRESS CODE: V03040003 I0" =
lines,
>> but I see no obvious lockup error message. Will those be fixed by =
your
>> qemu fix as well or are they caused by a different issue?
>>=20
>> [1] https://ci.debian.net/packages/d/dracut/testing/loong64/
>>=20
>=20
> The bug is actually a race condition in the internal CPU
> state emulated by qemu related to interrupt handling, As a result,
> the failure can happen randomly. In the log [1], I can see
> lock up messages during 70-iscsi. Regarding 60-nfs, I can see the
> direct reason for the failure is because of the unresponding
> nfs server. I guess the actual reason might still be the same.
> The lock up might happen on the vm served as nfs server.
>=20
> The message "PROGRESS CODE: " is printed by the firmware
> during initialization, which is normal and can be ignored.

As shown in the recent autopkgtest logs, the failure of dracut on =
loong64
should have been fixed after the upload of qemu 11.0.3+ds-2.

Cheers,

Miao Wang