On 5/8/25 19:05, Thomas Huth wrote:
On 08/05/2025 18.08, Paolo Bonzini wrote:
On 5/8/25 16:26, Stefan Hajnoczi wrote:
On Tue, May 6, 2025 at 11:30 AM Paolo Bonzini <pbonz...@redhat.com>
wrote:
The following changes since commit
a9e0c9c0f14e19d23443ac24c8080b4708d2eab8:
Merge tag 'pull-9p-20250505' of https://github.com/cschoenebeck/
qemu into staging (2025-05-05 11:26:59 -0400)
are available in the Git repository at:
https://gitlab.com/bonzini/qemu.git tags/for-upstream
for you to fetch changes up to
e6b9b79c3076777b791f72ebdbc9d37ad8005fe9:
gitlab: Enable CI for wasm build (2025-05-06 16:02:04 +0200)
----------------------------------------------------------------
* ci: enable RISC-V cross jobs
* rust: bump minimum supported version to 1.77
* rust: enable uninlined_format_args lint
* initial Emscripten support
* small fixes
I'm not sure why, but the following CI failure seems to be caused by
this pull request:
https://gitlab.com/qemu-project/qemu/-/jobs/9974291215#L4684
Please take a look, thanks!
It is a transient failure; it reproduces 30% of the time with
meson test --repeat 100 func-hppa-hppa_seabios
Please not that you should use -j1 when using --repeat ... otherwise the
same test will run in parallel multiple times and the instances might
destroy the output files of other tests while running.
Yes, I noticed that later but it also fails with
for i in $(seq 1 100); do
meson test --no-rebuild func-hppa-hppa_seabios
done
even without the pull request (commit
a9e0c9c0f14e19d23443ac24c8080b4708d2eab8).
Before finding this I had already sent the first half (which should be
safe since it's all Rust code that isn't compiled on that runner---and
for hppa targets in general), but if you still have the merge commit
perhaps you can push it?
Looking at the log and tests/functional/test_hppa_seabios.py, it seems
like this test just fires up the hppa BIOS, checks for some strings and
that's it. However, it seems like qemu-system-hppa quits completely if
the BIOS cannot boot from any device - so it's likely a race: QEMU quits
too fast, while the test still tries to talk to it to shut down QEMU
gracefully?
If I'm right this could likely be fixed by simply adding "-no-shutdown"
to the QEMU options here...?
Good idea!
Paolo
