On 5/29/26 11:49 AM, Richard Purdie 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, 2026-05-29 at 17:23 +0200, Alexander Kanavin via
lists.openembedded.org wrote:
On Fri, 29 May 2026 at 16:45, Quan Sun via lists.openembedded.org
<[email protected]> wrote:
glx: failed to create dri3 screen
failed to load driver: vgem
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3924
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3786
Can you have a look at the issue?
It seems this issue is not caused by the qemu upgrade. I also asked
an
AI agent to carefully examine the build/test logs, and the
following is
what it says:
Unfortunately AI has produced a total hallucination in its analysis,
because it looks only at the build log given to it, not at the actual
change that is being tested (e.g. it wouldn't see in that log that
there is a qemu update, and it wouldn't go and analyse the qemu own
changelog and commit history, and it wouldn't run the same test
against qemu 10.x to narrow it down and so on).
I went and tried this test with qemu 10.x on the same host, and it
passes just fine:
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3928
Then I cherry picked the qemu 11.x patch, and the test then fails:
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3930
It's still possible something is misconfigured on the host (it runs
tiger vnc standalone server to allow X clients such as qemu to render
into it), but the issue is clearly triggered by the version upgrade.
I should add, I looked into a couple of the failures on the autobuilder
and it appeared qemu is segfaulting after the upgrade. I'm fairly sure
that is related to the upgrade as it doesn't do it before.
Stack trace of thread 2714954:
#0 0x00007fec6367b4f4
__pthread_mutex_lock@GLIBC_2.2.5 (libc.so.6 + 0x924f4)
#1 0x00007fec603c0f40
wl_proxy_create_wrapper (libwayland-client.so.0 + 0x8f40)
#2 0x00007fec60182bc0
n/a (libEGL.so.1 + 0x2bbc0)
#3 0x00007fec6017a4e0
n/a (libEGL.so.1 + 0x234e0)
#4 0x00007fec6016aa9c
eglInitialize (libEGL.so.1 + 0x13a9c)
#5 0x00007fec64a89a8c
n/a (libSDL2-2.0.so.0 + 0xbaa8c)
#6 0x00007fec64a98226
n/a (libSDL2-2.0.so.0 + 0xc9226)
#7 0x00007fec64a9ab19
n/a (libSDL2-2.0.so.0 + 0xcbb19)
#8 0x0000558d31710aa4
n/a (qemu-system-x86_64 + 0x6acaa4)
#9 0x0000558d3171224e
n/a (qemu-system-x86_64 + 0x6ae24e)
#10 0x0000558d31710732
n/a (qemu-system-x86_64 + 0x6ac732)
#11 0x0000558d3164b554
n/a (qemu-system-x86_64 + 0x5e7554)
#12 0x0000558d313a8e59
n/a (qemu-system-x86_64 + 0x344e59)
#13 0x00007fec6360efab
__libc_start_call_main (libc.so.6 + 0x25fab)
#14 0x00007fec6360f0cb
__libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x260cb)
#15 0x0000558d313aa015
n/a (qemu-system-x86_64 + 0x346015)
Stack trace of thread
2714967:
#0 0x00007fec63680102
__syscall_cancel_arch (libc.so.6 + 0x97102)
#1 0x00007fec63674fb8
__internal_syscall_cancel (libc.so.6 + 0x8bfb8)
#2 0x00007fec6367529c
__futex_abstimed_wait_common (libc.so.6 + 0x8c29c)
#3 0x00007fec636779a8
pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x8e9a8)
#4 0x00007fec41996ff9
n/a (libgallium-26.0.6.so + 0x596ff9)
#5 0x00007fec41c64ee3
n/a (libgallium-26.0.6.so + 0x864ee3)
#6 0x00007fec41996f37
n/a (libgallium-26.0.6.so + 0x596f37)
#7 0x00007fec6367832c
start_thread (libc.so.6 + 0x8f32c)
#8 0x00007fec636f3b2c
__clone3 (libc.so.6 + 0x10ab2c)
[and more but probably not so interesting]
so it is failing in eglInitialize().
Cheers,
Richard
Hi Richard,
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.
Thanks,
Quan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#237764):
https://lists.openembedded.org/g/openembedded-core/message/237764
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]]
-=-=-=-=-=-=-=-=-=-=-=-
