Processing commands for cont...@bugs.debian.org:
> # no reply from the submitter in over two weeks, downgrade the severity
> # and reassign where it probably belongs
> tags 1040254 + moreinfo
Bug #1040254 [xserver-xorg-video-nouveau] xserver-xorg-video-nouveau:
Regression: Crashes with "(EE)
Using
export LIBVA_MESSAGING_LEVEL=2; export LIBVA_DRIVER_NAME=radeonsi; gdb
--directory . --directory ../libva-2.17.0 --directory ../mesa-22.3.6
--args /usr/bin/vainfo
I've stepped through vainfo and focused on va_openDriver() which
eventually leads to:
(gdb) n
libva info: Found init
The mesa-va-drivers-dbgsym package seems to have incorrect (relative to
build) paths stored which prevents gdb showing the source lines when it
has the path to the mesa-22.6.3 source, however by blindly stepping and
then looking at the source it narrows down the cause:
(gdb) s
126 in
Power-off reboot fixed the issue, so can mark this bug report as invalid
or similar.
$ vainfo
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
After a walk and a think I sensibly stepped back and realised Xorg.0.log
reports problems and with that clue so does the kernel (but I hadn't
noticed!). I *suspect* this may be related to having kexec-ed into the
current kernel. I'm going to try a poweroff restart after this report:
$ grep -E
After solving the relative path issue I now have better info:
(gdb) s
__vaDriverInit_1_17 (ctx=0x555702b0) at
../src/gallium/frontends/va/context.c:123
123if (!ctx)
(gdb) n
126drv = CALLOC(1, sizeof(vlVaDriver));
(gdb) n
127if (!drv)
(gdb) n
130switch
Package: libgl1-mesa-dri
Version: 22.3.6-1+deb12u1
Severity: normal
Tags: patch
Dear Maintainer,
Screen freeze because gnome-shell waits DRM_IOCTL_SYNCOBJ_WAIT forever in
Wayland mode when resource is tight. See
https://gitlab.freedesktop.org/drm/intel/-/issues/6851 for details.
This problem
7 matches
Mail list logo
