On Fri, 29 May 2026 at 18:47, Quan Sun via lists.openembedded.org
<[email protected]> wrote:
> 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.

qemu 10.x does not crash, or silently fail, and it is able to open sdl
and gtk windows even on headless hosts without GPU. Yocto CI is
specifically set up to support it: it's runing Tiger VNC server that X
clients (such as qemu) can connect to, and qemu is using mesa's
llvmpipe renderer which does not require a physical GPU.

Are you using AI to write out argumentation here as well, or are these
your own thoughts? Please be clear about this. I'd be happy to correct
you, but I would not want to spend too much time time correcting AI,
because I don't think it is going to provide sudden helpful insights.
To get to the bottom of it, someone needs to set up a gdb session and
step through the code of 11.x and 10.x initializations, finding out
why one falls through to the crashing wayland step, and the other does
not. AI is not capable of doing that kind of reproducing the issue,
and then debugging it, not yet at least.

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

  • [OE-core][PATCH] qe... Quan Sun via lists.openembedded.org
    • Re: [OE-core][... Mathieu Dubois-Briand via lists.openembedded.org
      • Re: [OE-co... Quan Sun via lists.openembedded.org
        • Re: [O... Alexander Kanavin via lists.openembedded.org
          • Re... Richard Purdie via lists.openembedded.org
            • ... Quan Sun via lists.openembedded.org
              • ... Alexander Kanavin via lists.openembedded.org
              • ... Quan Sun via lists.openembedded.org
              • ... Alexander Kanavin via lists.openembedded.org
              • ... Quan Sun via lists.openembedded.org
              • ... Alexander Kanavin via lists.openembedded.org
              • ... Philippe Mathieu-Daudé via lists . openembedded . org
              • ... Daniel P . Berrangé via lists . openembedded . org
              • ... Alexander Kanavin via lists.openembedded.org
              • ... Alexander Kanavin via lists.openembedded.org
              • ... Alexander Kanavin via lists.openembedded.org
              • ... Alexander Kanavin via lists.openembedded.org
              • ... Quan Sun via lists.openembedded.org
              • ... Alexander Kanavin via lists.openembedded.org

Reply via email to