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