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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#237766): https://lists.openembedded.org/g/openembedded-core/message/237766 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]] -=-=-=-=-=-=-=-=-=-=-=-
