[Bug 2120835] [NEW] EDK2 tests for riscv emulation fail against qemu 10.1 (but only on ppc64 and armhf)
Christian Ehrhardt
2120835 at bugs.launchpad.net
Mon Aug 18 11:04:54 UTC 2025
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
Foundations Bugs, which is subscribed to edk2 in Ubuntu.
https://bugs.launchpad.net/bugs/2120835
Title:
EDK2 tests for riscv emulation fail against qemu 10.1 (but only on
ppc64 and armhf)
Status in edk2 package in Ubuntu:
New
Bug description:
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
(?!?) ?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2120835/+subscriptions
More information about the foundations-bugs
mailing list