On 5/29/26 12:29 PM, Alexander Kanavin wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Fri, 29 May 2026 at 18:10, Quan Sun via lists.openembedded.org
<[email protected]> wrote:
This is likely a real QEMU 11.0 regression, but may not be in QEMU's
code itself. The QEMU 11.0 likely changed its display initialization to
be multi-threaded or reordered it, triggering a race condition in the
host's Wayland/EGL/Mesa stack. Maybe setting SDL_VIDEODRIVER=x11 could
solve the issue.
This issue is different from the "glx: failed to create dri3 screen /
failed to load driver: vgem error" seen earlier, which was a missing GPU
driver issue on the host.
If you have any detailed logs, please share with me and so I have more
contexts.
It's the same issue, I assure you. Qemu 10.x prints nothing and simply
starts, while qemu 11.x first tries glx/dri3 , then wayland/egl/vgem
(even though there's no wayland running on the build hosts), and then
finally crashes, with the traceback that RP provided.
I don't think it's a race condition, as the failure is deterministic,
but I agree that something has changed in qemu's GL initialization
sequence.
Unfortunately there are no more detailed logs than this. We've
considered disabling this test, as accelerated rendering directly into
gtk/sdl windows is tricky to support, complicated to reproduce (with
regressions like this), and has limited use. I've promised RP to write
up a proposal to oe-architecture, and I'll get to it :)
Alex
Then it could be this:
The QEMU 11.0 changed its GL display initialization sequence. On
headless build hosts (no Wayland, no proper GPU), QEMU 10.x would
silently fall through and start, while QEMU 11.0 now probes more
aggressively:
1. Tries GLX/DRI3 → fails (glx: failed to create dri3 screen, failed to
load driver: vgem)
2. Tries Wayland/EGL → crashes (the segfault in eglInitialize →
wl_proxy_create_wrapper)
It's not a race — it's a deterministic crash because QEMU 11.0's new
init path tries
to call into Wayland client code on a host where Wayland isn't running,
and that code
path hits a NULL pointer or invalid state in wl_proxy_create_wrapper.
Still, the upgrade itself may be fine — all actual QEMU
functionality works (685/686 tests pass). The single failure is in
test_testimage_virgl_gtk_sdl, which tests hardware-accelerated GL
rendering into a GTK
/SDL window — something that doesn't work on headless CI hosts
regardless, and QEMU
11.0 just crashes harder than 10.x did when it fails. The test itself
may be a candidate
for removal/rework.
-Quan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#237767):
https://lists.openembedded.org/g/openembedded-core/message/237767
Mute This Topic: https://lists.openembedded.org/mt/119486545/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
