> 2026年7月22日 06:39，Benjamin Drung <[email protected]> 写道： > > 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, >>> >>> 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). >>>> >>>> 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. >>> >>> >>> I've scheduled a run manually. Let's see how it fares. >> >> 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]. > > 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: > > 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 > > 21-overlayfs and 30-dmsquash wich should be fixed by your qemu fix I > assume. > > 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? > > [1] https://ci.debian.net/packages/d/dracut/testing/loong64/ >
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. The message "PROGRESS CODE: " is printed by the firmware during initialization, which is normal and can be ignored. Cheers, Miao Wang [1]: https://ci.debian.net/data/autopkgtest/testing/loong64/d/dracut/73387522/log.gz
