Public bug reported: In testing qemu 10.1 we've seen them start to fail on armhf and ppc64 (only there)
https://autopkgtest.ubuntu.com/packages/e/edk2/questing/armhf https://autopkgtest.ubuntu.com/packages/e/edk2/questing/ppc64el An example log is https://autopkgtest.ubuntu.com/results/autopkgtest-questing/questing/ppc64el/e/edk2/20250818_045238_153f0@/log.gz With a porterbox setup the good case is reproducible like this: sudo apt install -y ovmf ovmf-ia32 python3-pexpect qemu-efi-aarch64 qemu-efi-arm qemu-efi-loongarch64 qemu-efi-riscv64 qemu-system-arm qemu-system-loongarch64 qemu-system-riscv64 qemu-system-x86 apt source edk2 cd edk2-2025.02/ PYTHONPATH=./debian/python python3 debian/tests/shell.py PYTHONPATH=./debian/python python3 debian/tests/shell.py 2>&1 | tee -a ~/compare-10.0.log ... works fine Switching to the qemu 10.1 (and by dependency glibc) from proposed makes this reproducible. The error (or red herring) is 241s ERROR:target/riscv/pmu.c:216:riscv_pmu_icount_update_priv: assertion failed: (newpriv <= PRV_S) 241s Bail out! ERROR:target/riscv/pmu.c:216:riscv_pmu_icount_update_priv: assertion failed: (newpriv <= PRV_S) 251s ERROR PMU again - really? - /me is shaking the fist! And inside the test that is 251s ====================================================================== 251s ERROR: test_riscv64 (__main__.BootToShellTest.test_riscv64) 251s ---------------------------------------------------------------------- 251s Traceback (most recent call last): 251s File "/tmp/autopkgtest.RPBps3/build.f20/src/debian/tests/shell.py", line 100, in run_cmd_check_shell 251s i = child.expect( 251s [ 251s ...<3 lines>... 251s timeout=TEST_TIMEOUT, 251s ) 251s File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 354, in expect 251s return self.expect_list(compiled_pattern_list, 251s ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^ 251s timeout, searchwindowsize, async_) 251s ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 251s File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 383, in expect_list 251s return exp.expect_loop(timeout) 251s ~~~~~~~~~~~~~~~^^^^^^^^^ 251s File "/usr/lib/python3/dist-packages/pexpect/expect.py", line 179, in expect_loop 251s return self.eof(e) 251s ~~~~~~~~^^^ 251s File "/usr/lib/python3/dist-packages/pexpect/expect.py", line 122, in eof 251s raise exc AFAICS this very much comes down to 251s args: [b'/usr/bin/qemu-system-riscv64', b'-no-user-config', b'-nodefaults', b'-m', b'256', b'-smp', b'1,sockets=1,cores=1,threads=1', b'-display', b'none', b'-serial', b'stdio', b'-machine', b'virt', b'-device', b'virtio-serial-device', b'-drive', b'file=/usr/share/qemu-efi- riscv64/RISCV_VIRT_CODE.fd,if=pflash,format=raw,unit=0,readonly=on', b'-drive', b'file=/tmp/tmpr31gjfit,if=pflash,format=raw,unit=1,readonly=off'] From here I have two log filed for 10.0 and 10.1 which we can compare, but the diff shows no interesting Delta until the bug happens. I need to modify the test to keep the artifacts around and allow it to be ran directly. We can steal the test drive from the test (will attach) and then isolate the command: Command: qemu-system-riscv64 -no-user-config -nodefaults -m 256 -smp '1,sockets=1,cores=1,threads=1' -display 'none' -serial 'stdio' -machine 'virt' -device 'virtio-serial-device' -drive 'file=/usr/share/qemu-efi-riscv64/RISCV_VIRT_CODE.fd,if=pflash,format=raw,unit=0,readonly=on' -drive 'file=/tmp/testdrive,if=pflash,format=raw,unit=1,readonly=off' Riddles: At least in automation they only fail on armhf and ppc64 (?!?) ? ** Affects: edk2 (Ubuntu) Importance: Undecided Status: New ** Tags: server-todo -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2120835 Title: EDK2 tests for riscv emulation fail against qemu 10.1 (but only on ppc64 and armhf) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2120835/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
