xserver issueshttps://gitlab.freedesktop.org/xorg/xserver/-/issues2023-10-27T08:48:04Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1380xwayland: Create a xwl_gbm context for each available GPU2023-10-27T08:48:04ZAustin Shaferxwayland: Create a xwl_gbm context for each available GPUXwayland currently only creates one `xwl_gbm` instance corresponding to the primary GPU. This is then used in `glamor_pixmap_from_fds` to import buffers as part of creating a pixmap for a buffer. This is an issue because in multi-GPU PRI...Xwayland currently only creates one `xwl_gbm` instance corresponding to the primary GPU. This is then used in `glamor_pixmap_from_fds` to import buffers as part of creating a pixmap for a buffer. This is an issue because in multi-GPU PRIME environments we are starting to consider scenarios where we want to directly scan out clients running on the dGPU. Trying to import dGPU-specific buffers with scanout modifiers fails since the `xwl_gbm` object is not created on the dGPU.
What most likely needs to happen is we need to create a `xwl_gbm` (and associated context) for each GPU in the system. We could then probably use something like the new `DRMSetDeviceInUse` request from DRI3 to look up the correct gbm context to import a buffer into while creating a pixmap.
This issue exists to document this problem and start a discussion on how to improve it. This is related to !818https://gitlab.freedesktop.org/xorg/xserver/-/issues/1166Xwayland doesn't filter out modifiers not supported by GBM2021-11-27T18:32:37ZSimon Sercontact@emersion.frXwayland doesn't filter out modifiers not supported by GBM1. Start gamescope, a Vulkan-based Wayland compositor, on an AMD GPU
2. Set `R600_DEBUG=nodcc` to disable some AMD modifiers for EGL/GBM users
3. Start vkcube, a Vulkan client
Both the compositor and the client will support AMD DCC modi...1. Start gamescope, a Vulkan-based Wayland compositor, on an AMD GPU
2. Set `R600_DEBUG=nodcc` to disable some AMD modifiers for EGL/GBM users
3. Start vkcube, a Vulkan client
Both the compositor and the client will support AMD DCC modifiers. However Xwayland won't (because GBM support for DCC modifiers is disabled by the env). This will result in a `BadAlloc` error sent to the client as a reply to `DRI3PixmapFromBuffers`.
Xwayland should filter out any modifier advertised by the parent compositor that it doesn't support.
Here this happens because of an env var, this could also happen because support for a new modifier has been plumbed in Vulkan but not in EGL yet.
Original issue: https://github.com/Plagman/gamescope/issues/185https://gitlab.freedesktop.org/xorg/xserver/-/issues/1107DRI1 SIGIO handling is non-functional2021-06-25T06:02:21ZAlan CoopersmithDRI1 SIGIO handling is non-functionalAs noted in the now-withdrawn !555, since @keithp removed the setting of `xf86Info.useSIGIO` in commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99 the code in hw/xfree86/os-support/shared/sigio.c is effectively all dead code now, as it's bl...As noted in the now-withdrawn !555, since @keithp removed the setting of `xf86Info.useSIGIO` in commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99 the code in hw/xfree86/os-support/shared/sigio.c is effectively all dead code now, as it's blocked behind a check for that variable.
The only remaining callers of that code are in hw/xfree86/dri/dri.c, and have apparently been running without SIGIO support since 2015.
If DRI1 doesn't really need this code any more, then the SIGIO code can be deleted in hw/xfree86/dri/dri.c and the sigio.c & sigiostubs.c files can be deleted from os-support/shared and the various os-support Makefiles.
But if DRI does need this code (despite people apparently not noticing since 2015), then a change such as !555 is needed to make it actually work.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1053xorg-server-1.20.{7,8} crash with dixGetPrivateAddr: Assertion `key->initiali...2023-03-29T05:57:49ZJaak Ristiojaxorg-server-1.20.{7,8} crash with dixGetPrivateAddr: Assertion `key->initialized' failed when starting spice-gtkFrom downstream bug report: https://bugs.gentoo.org/729036
Starting /usr/bin/spicy from spice-gtk-0.37 immediately crashes the Xorg server:
```
X: ../../../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed....From downstream bug report: https://bugs.gentoo.org/729036
Starting /usr/bin/spicy from spice-gtk-0.37 immediately crashes the Xorg server:
```
X: ../../../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed.
```
From the GDB log:
```
X: ../../../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed.
Thread 1 "X" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set =
{__val = {0, 140737348803552, 18384884767774310400, 93825004694704, 93825004694704, 93825004694704, 93825004694704, 93825004694796, 93825004694804, 93825004694704, 93825004694804, 0, 0, 0, 0, 0}}
pid = <optimized out>
tid = <optimized out>
#1 0x00007ffff7a9155d in __GI_abort () at abort.c:79
save_stage = 1
act =
{__sigaction_handler = {sa_handler = 0x555556136cb0, sa_sigaction = 0x555556136cb0}, sa_mask = {__val = {0, 93825004694704, 92, 140737349893260, 47244640784, 0, 0, 0, 21474836480, 140737488346096, 0, 140737349916080, 18285507533332519680, 0, 140737340698624, 140737349900920}}, sa_flags = 1433528956, sa_restorer = 0x55555571a0a6}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007ffff7a91431 in __assert_fail_base
(fmt=0x7ffff7bf5a78 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55555571a0a6 "key->initialized", file=0x55555571ea7c "../../../include/privates.h", line=<optimized out>, function=<optimized out>) at assert.c:92
str = 0x555556136cb0 " )\023VUU"
total = 4096
#3 0x00007ffff7aa0442 in __GI___assert_fail
(assertion=assertion@entry=0x55555571a0a6 "key->initialized", file=file@entry=0x55555571ea7c "../../../include/privates.h", line=line@entry=121, function=function@entry=0x55555573d720 <__PRETTY_FUNCTION__.7> "dixGetPrivateAddr")
at assert.c:101
#4 0x00005555556d34f5 in dixGetPrivateAddr
(key=0x5555557b8ba0 <dri2ClientPrivateKeyRec>, privates=0x555555838060)
at ../../../include/privates.h:121
__PRETTY_FUNCTION__ = "dixGetPrivateAddr"
#5 0x00005555556d583c in dixGetPrivateAddr
(key=<optimized out>, privates=<optimized out>) at dri2.c:1371
__PRETTY_FUNCTION__ = "dixGetPrivateAddr"
ds = <optimized out>
dri2_client = <optimized out>
primescreen = <optimized out>
#6 dixLookupPrivate (key=<optimized out>, privates=<optimized out>)
at ../../../include/privates.h:164
ds = <optimized out>
dri2_client = <optimized out>
primescreen = <optimized out>
#7 DRI2Authenticate
(client=client@entry=0x555556162ea0, pScreen=0x555555837ff0, magic=1)
at dri2.c:1367
ds = <optimized out>
dri2_client = <optimized out>
primescreen = <optimized out>
#8 0x00005555556d65d2 in ProcDRI2Authenticate (client=0x555556162ea0)
at dri2ext.c:152
stuff = 0x555555f941f0
rep =
{type = 0 '\000', pad1 = 0 '\000', sequenceNumber = 0, length = 0, authenticated = 1433434916, pad2 = 21845, pad3 = 1444294304, pad4 = 359, pad5 = 1, pad6 = 0}
pDraw = 0x555555910a70
status = 0
stuff = 0x555555f941f0
#9 ProcDRI2Dispatch (client=0x555556162ea0) at dri2ext.c:609
stuff = 0x555555f941f0
#10 0x00005555555abffd in Dispatch () at dispatch.c:478
result = <optimized out>
client = 0x555556162ea0
start_tick = 235
#11 0x00005555555b0113 in dix_main
(argc=13, argv=0x7fffffffdf98, envp=<optimized out>) at main.c:276
i = <optimized out>
alwaysCheckForInput = {0, 1}
#12 0x00007ffff7a92d6b in __libc_start_main (main=
0x555555599730 <main>, argc=13, argv=0x7fffffffdf98, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdf88)
at ../csu/libc-start.c:308
result = <optimized out>
unwind_buf =
{cancel_jmp_buf = {{jmp_buf = {0, 4918808907280168905, 93824992515904, 140737488347024, 0, 0, 1231254831528032201, 1231271685478430665}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7fffffffe008, 0x7ffff7ffe130}, data = {prev = 0x0, cleanup = 0x0, canceltype = -8184}}}
not_first_call = <optimized out>
#13 0x000055555559976a in _start () at dri2ext.c:659
(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/X (OsLookupColor+0x135) [0x555555708f95]
(EE) 1: /lib64/libc.so.6 (killpg+0x40) [0x7ffff7aa7e3f]
(EE) 2: /lib64/libc.so.6 (gsignal+0x141) [0x7ffff7aa7d81]
(EE) 3: /lib64/libc.so.6 (abort+0x127) [0x7ffff7a9155d]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 4: /lib64/libc.so.6 (?+0x0) [0x7ffff7a91422]
(EE) 5: /lib64/libc.so.6 (__assert_fail+0x42) [0x7ffff7aa0442]
(EE) 6: /usr/bin/X (DRIMoveBuffersHelper+0xc85) [0x5555556d4155]
(EE) 7: /usr/bin/X (DRI2Authenticate+0xec) [0x5555556d583c]
(EE) 8: /usr/bin/X (DRI2GetParam+0x6c2) [0x5555556d6962]
(EE) 9: /usr/bin/X (SendErrorToClient+0x35d) [0x5555555ac05d]
(EE) 10: /usr/bin/X (InitFonts+0x3a3) [0x5555555b0153]
(EE) 11: /lib64/libc.so.6 (__libc_start_main+0xeb) [0x7ffff7a92d6b]
(EE) 12: /usr/bin/X (_start+0x2a) [0x55555559976a]
(EE)
(EE)
Fatal server error:
(EE) Caught signal 6 (Aborted). Server aborting
(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
Thread 1 "X" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 in ../sysdeps/unix/sysv/linux/raise.c
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/205coredump trying to stop xorg (Radeon RX 550)2018-12-13T18:32:13ZBugzilla Migration Usercoredump trying to stop xorg (Radeon RX 550)## Submitted by Markus N.
Assigned to **Xorg Project Team**
**[Link to original bug (#105431)](https://bugs.freedesktop.org/show_bug.cgi?id=105431)**
## Description
Created attachment 137976
coredump stopping xorg
I'm currently f...## Submitted by Markus N.
Assigned to **Xorg Project Team**
**[Link to original bug (#105431)](https://bugs.freedesktop.org/show_bug.cgi?id=105431)**
## Description
Created attachment 137976
coredump stopping xorg
I'm currently facing two issues that I think are related:
1) When I try to suspend the computer from the desktop environment (XFCE), it immediately freezes.
2) When I stop xorg from the console (systemctl stop lxdm), xorg crashes with a coredump. The computer is still responsive, until I switch to console 7 (alt-F7), then it also freezes.
Kernel and Xorg versions:
X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.14.12-1-ARCH x86_64
Current Operating System: Linux TuxServer 4.15.7-1-ARCH #1 SMP PREEMPT Wed Feb 28 19:01:57 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=/dev/mapper/SystemGroup-arch_prod rw quiet ipv6.disable=1 ipv6.disable_ipv6=1 amdgpu.dc=0
Build Date: 26 January 2018 10:25:18AM
Graphics hardware: Radeon RX 550 4GB
Currently I'm using the xf86-video-ati driver, _not_ amdgpu. With amdgpu, the issue also occurs.
I have three computers with the same operating system, all of them up-to-date, but the issue only occurs on the computer with the Radeon RX 550. The other ones have an older AMD graphics card (Radon HD 5450) respectively intel on-chip graphics (Celeron J 3455)
I've attached the core dump, and this is what I get in the system journal:
Mar 09 18:40:27 TuxServer systemd[1]: Stopping LXDE Display Manager...
-- Subject: Unit lxdm.service has begun shutting down
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit lxdm.service has begun shutting down.
Mar 09 18:40:27 TuxServer systemd[1]: Started Process Core Dump (PID 1238/UID 0).
-- Subject: Unit systemd-coredump@1-1238-0.service has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit systemd-coredump@1-1238-0.service has finished starting up.
--
-- The start-up result is RESULT.
Mar 09 18:40:27 TuxServer systemd-coredump[1239]: Removed old coredump core.xfce4-sensors-p.1000.e53d1acd50b143d9924b52a7cb65fc7e.929.1520617120000000.lz4.
Mar 09 18:40:27 TuxServer systemd[1]: Stopped LXDE Display Manager.
-- Subject: Unit lxdm.service has finished shutting down
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit lxdm.service has finished shutting down.
Mar 09 18:40:27 TuxServer systemd-coredump[1239]: Process 733 (Xorg) of user 0 dumped core.
Stack trace of thread 733:
#0 0x00007f114863a860 raise (libc.so.6)
#1 0x00007f114863bec9 abort (libc.so.6)
#2 0x000055c5d826dcea OsAbort (Xorg)
#3 0x000055c5d8149674 ddxGiveUp (Xorg)
#4 0x000055c5d82737e2 n/a (Xorg)
#5 0x000055c5d8274625 FatalError (Xorg)
#6 0x000055c5d826adde n/a (Xorg)
#7 0x00007f11489cedd0 __restore_rt (libpthread.so.0)
#8 0x000055c5d823b063 DRI2CloseScreen (Xorg)
#9 0x00007f1144c41d68 n/a (modesetting_drv.so)
#10 0x000055c5d8178b37 n/a (Xorg)
#11 0x000055c5d81e5c02 n/a (Xorg)
#12 0x000055c5d8197250 n/a (Xorg)
#13 0x000055c5d8109390 n/a (Xorg)
#14 0x00007f1148626f4a __libc_start_main (libc.so.6)
#15 0x000055c5d80f2f0a _start (Xorg)
Stack trace of thread 758:
#0 0x00007f11489ca3bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00007f1142e8bfbc n/a (radeonsi_dri.so)
#2 0x00007f1142e8bec8 n/a (radeonsi_dri.so)
#3 0x00007f11489c408c start_thread (libpthread.so.0)
#4 0x00007f11486fbe7f __clone (libc.so.6)
Stack trace of thread 757:
#0 0x00007f11489ca3bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00007f1142e8bfbc n/a (radeonsi_dri.so)
#2 0x00007f1142e8bec8 n/a (radeonsi_dri.so)
#3 0x00007f11489c408c start_thread (libpthread.so.0)
#4 0x00007f11486fbe7f __clone (libc.so.6)
Stack trace of thread 751:
#0 0x00007f11489ca3bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00007f1142e8bfbc n/a (radeonsi_dri.so)
#2 0x00007f1142e8bec8 n/a (radeonsi_dri.so)
#3 0x00007f11489c408c start_thread (libpthread.so.0)
#4 0x00007f11486fbe7f __clone (libc.so.6)
Stack trace of thread 756:
#0 0x00007f11489ca3bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00007f1142e8bfbc n/a (radeonsi_dri.so)
#2 0x00007f1142e8bec8 n/a (radeonsi_dri.so)
#3 0x00007f11489c408c start_thread (libpthread.so.0)
#4 0x00007f11486fbe7f __clone (libc.so.6)
Stack trace of thread 754:
#0 0x00007f11489ca3bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00007f1142e8bfbc n/a (radeonsi_dri.so)
#2 0x00007f1142e8bec8 n/a (radeonsi_dri.so)
#3 0x00007f11489c408c start_thread (libpthread.so.0)
#4 0x00007f11486fbe7f __clone (libc.so.6)
Stack trace of thread 753:
#0 0x00007f11489ca3bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00007f1142e8bfbc n/a (radeonsi_dri.so)
#2 0x00007f1142e8bec8 n/a (radeonsi_dri.so)
#3 0x00007f11489c408c start_thread (libpthread.so.0)
#4 0x00007f11486fbe7f __clone (libc.so.6)
Stack trace of thread 755:
#0 0x00007f11489ca3bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00007f1142e8bfbc n/a (radeonsi_dri.so)
#2 0x00007f1142e8bec8 n/a (radeonsi_dri.so)
#3 0x00007f11489c408c start_thread (libpthread.so.0)
#4 0x00007f11486fbe7f __clone (libc.so.6)
Stack trace of thread 761:
#0 0x00007f11489ca3bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00007f1142e8bfbc n/a (radeonsi_dri.so)
#2 0x00007f1142e8bec8 n/a (radeonsi_dri.so)
#3 0x00007f11489c408c start_thread (libpthread.so.0)
#4 0x00007f11486fbe7f __clone (libc.so.6)
-- Subject: Process 733 (Xorg) dumped core
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: man:core(5)
--
-- Process 733 (Xorg) crashed and dumped core.
--
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.
**Attachment 137976**, "coredump stopping xorg":
[core.Xorg.0.e53d1acd50b143d9924b52a7cb65fc7e.733.1520617227000000.lz4](/uploads/03ecabc9617bda604582b5a4cfafda1e/core.Xorg.0.e53d1acd50b143d9924b52a7cb65fc7e.733.1520617227000000.lz4)https://gitlab.freedesktop.org/xorg/xserver/-/issues/208after "xfree86: Adding drm device (/dev/dri/card0" Segment fault2021-03-25T22:40:09ZBugzilla Migration Userafter "xfree86: Adding drm device (/dev/dri/card0" Segment fault## Submitted by wfeng
Assigned to **Xorg Project Team**
**[Link to original bug (#97897)](https://bugs.freedesktop.org/show_bug.cgi?id=97897)**
## Description
lucid@mircomBook:~$ cat .local/share/xorg/Xorg.0.log .
[ 54.527]
X.O...## Submitted by wfeng
Assigned to **Xorg Project Team**
**[Link to original bug (#97897)](https://bugs.freedesktop.org/show_bug.cgi?id=97897)**
## Description
lucid@mircomBook:~$ cat .local/share/xorg/Xorg.0.log .
[ 54.527]
X.Org X Server 1.18.3
Release Date: 2016-04-04
[ 54.527] X Protocol Version 11, Revision 0
[ 54.528] Build Operating System: Linux 4.2.0-42-generic armv7l Ubuntu
[ 54.528] Current Operating System: Linux mircomBook 4.4.20-armv7-x10 #1 SMP Mon Sep 12 12:25:03 PDT 2016 armv7l
[ 54.528] Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait fixrtc
[ 54.528] Build Date: 22 July 2016 07:53:12AM
[ 54.529] xorg-server 2:1.18.3-1ubuntu2.3 (For technical support please see h ttp://www.ubuntu.com/support)
[ 54.529] Current version of pixman: 0.33.6
[ 54.529] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 54.529] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 54.970] (==) Log file: "/home/lucid/.local/share/xorg/Xorg.0.log", Time: We d Sep 21 21:55:58 2016
[ 54.971] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 54.973] (==) No Layout section. Using the first Screen section.
[ 54.973] (==) No screen section available. Using defaults.
[ 54.973] (**) |-->Screen "Default Screen Section" (0)
[ 54.973] (**) | |-->Monitor "`<default monitor>`"
[ 54.974] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 54.974] (==) Automatically adding devices
[ 54.974] (==) Automatically enabling devices
[ 54.974] (==) Automatically adding GPU devices
[ 54.974] (==) Max clients allowed: 256, resource mask: 0x1fffff
[ 54.974] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 54.974] Entry deleted from font path.
[ 54.974] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[ 54.974] Entry deleted from font path.
[ 54.974] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[ 54.974] Entry deleted from font path.
[ 54.974] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist.
[ 54.974] Entry deleted from font path.
[ 54.975] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[ 54.975] Entry deleted from font path.
[ 54.975] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[ 54.975] Entry deleted from font path.
[ 54.975] (==) FontPath set to:
/usr/share/fonts/X11/misc,
built-ins
[ 54.975] (==) ModulePath set to "/usr/lib/arm-linux-gnueabihf/xorg/extra-mod ules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
[ 54.975] (II) The server relies on udev to provide the list of input devices .
If no devices become available, reconfigure udev or disable AutoAddDevic es.
[ 54.975] (II) Loader magic: 0x7f700f60
[ 54.975] (II) Module ABI versions:
[ 54.975] X.Org ANSI C Emulation: 0.4
[ 54.975] X.Org Video Driver: 20.0
[ 54.975] X.Org XInput driver : 22.1
[ 54.975] X.Org Server Extension : 9.0
[ 54.984] (++) using VT number 1
[ 54.998] (II) systemd-logind: took control of session /org/freedesktop/login 1/session/_32
[ 55.001] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 55.004] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 8 paused 0
[ 55.005] (EE)
[ 55.006] (EE) Backtrace:
[ 55.006] (EE)
[ 55.006] (EE) Segmentation fault at address 0x0
[ 55.006] (EE)
Fatal server error:
[ 55.006] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 55.006] (EE)
[ 55.006] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 55.007] (EE) Please also check the log file at "/home/lucid/.local/share/xo rg/Xorg.0.log" for additional information.
[ 55.007] (EE)
cat: .: Is a directory
lucid@mircomBook:~$ systemd-logind: got fd for /dev/dri/card0 226:0 fd 8 paused 0
###
The uname -a
Linux mircomBook 4.4.20-armv7-x10 #1 SMP Mon Sep 12 12:25:03 PDT 2016 armv7l armv7l armv7l GNU/Linuxhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/206glx/dri* blocks GLX clients on VT switch2021-11-13T09:24:36ZBugzilla Migration Userglx/dri* blocks GLX clients on VT switch## Submitted by Gatis Paeglis
Assigned to **Xorg Project Team**
**[Link to original bug (#91448)](https://bugs.freedesktop.org/show_bug.cgi?id=91448)**
## Description
Created attachment 117339
xcb test code
resulted from https://...## Submitted by Gatis Paeglis
Assigned to **Xorg Project Team**
**[Link to original bug (#91448)](https://bugs.freedesktop.org/show_bug.cgi?id=91448)**
## Description
Created attachment 117339
xcb test code
resulted from https://bugreports.qt.io/browse/QTBUG-47179
The issue is reproducible also in other situations, for example when "session / screen is locked by Light Locker (Xubuntu, standard configuration)"
xcb test code in the attachment.
Code works as expected when glx extension is not initialized. As soon as you enable glx extension you start to get a blocking behaviour on xcb_get_input_focus_reply;
Expected outcome when switching to VT:
syncX: 12:20:30
syncX: 12:20:31
syncX: 12:20:32
syncX: 12:20:33
syncX: 12:20:34
syncX: 12:20:35
syncX: 12:20:36
syncX: 12:20:37
syncX: 12:20:38
syncX: 12:20:39
syncX: 12:20:40
syncX: 12:20:41
Actual outcome (switch to VT and then back to GUI session after for example 5 seconds):
syncX: 12:20:30
syncX: 12:20:31
syncX: 12:20:32
syncX: 12:20:33
syncX: 12:20:39
syncX: 12:20:40
syncX: 12:20:41
**Attachment 117339**, "xcb test code":
[main.cpp](/uploads/4be9a0faebd037a31e43f63597b74e2f/main.cpp)https://gitlab.freedesktop.org/xorg/xserver/-/issues/203Input lag playing Strife with dri3 enabled2018-12-13T18:32:02ZBugzilla Migration UserInput lag playing Strife with dri3 enabled## Submitted by Lorenzo Bona
Assigned to **Xorg Project Team**
**[Link to original bug (#90798)](https://bugs.freedesktop.org/show_bug.cgi?id=90798)**
## Description
Hi.
I'm facing an issue running this game (Strife).
For example...## Submitted by Lorenzo Bona
Assigned to **Xorg Project Team**
**[Link to original bug (#90798)](https://bugs.freedesktop.org/show_bug.cgi?id=90798)**
## Description
Hi.
I'm facing an issue running this game (Strife).
For example, in menus, when I type my password for the login I can see lags between the key press and the type being displayed on the screen.
If I click on buttons nothing happens until I move the coursor.
Same things happen during the gameplay.
When I disable dri3 (from xorg.conf) and run this game on dri2 all seems correct, working as expected, none input lag at all.
I'm building driver, drm, mesa and xorg from git and kernel from Dave Airlie's git (branch drm-fixes-4.1).
What log do you need guys: Xorg, Mesa?
Thank you.
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/201x segfault, pixmap is null in present_copy_region2018-12-13T18:31:56ZBugzilla Migration Userx segfault, pixmap is null in present_copy_region## Submitted by Christoph Haag
Assigned to **Xorg Project Team**
**[Link to original bug (#90495)](https://bugs.freedesktop.org/show_bug.cgi?id=90495)**
## Description
Created attachment 115860
bt full
This happened with current ...## Submitted by Christoph Haag
Assigned to **Xorg Project Team**
**[Link to original bug (#90495)](https://bugs.freedesktop.org/show_bug.cgi?id=90495)**
## Description
Created attachment 115860
bt full
This happened with current xorg stable, but I couldn't compile it with gcc 5.1, so gdb.txt was created to current git master.
xf86-video-intel git master compiled with ./autogen.sh --enable-dri --with-default-accel=sna --with-default-dri=3
I can provoke it with simply starting the Crashed Lander demo
http://don-whitaker.itch.io/crashedlander
But I don't think it happens every time. Possibly the oculus rift service needs to be running and possibly replacing the Plugins/libOculus.so with the current version from the oculus download section has something to do with it too... Not sure.
If intel ddx full debug log is required, I can create that too...
**Attachment 115860**, "bt full":
[gdb.txt](/uploads/e52f870bf8120c63f7d14f7f7b8953ec/gdb.txt)
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/204Xorg does not close old /dev/dri/card0 connections2022-11-16T23:33:01ZBugzilla Migration UserXorg does not close old /dev/dri/card0 connections## Submitted by Isabelle
Assigned to **Xorg Project Team**
**[Link to original bug (#86665)](https://bugs.freedesktop.org/show_bug.cgi?id=86665)**
## Description
Recently I've been getting a lot of "maximum number of x clients rea...## Submitted by Isabelle
Assigned to **Xorg Project Team**
**[Link to original bug (#86665)](https://bugs.freedesktop.org/show_bug.cgi?id=86665)**
## Description
Recently I've been getting a lot of "maximum number of x clients reached" errors. On my computer I run two X servers. I switch between them pretty regularly with crtl+alt+f1/f2.
I've been trying to figure out why I keep getting this error. xlsclients only lists 12 items, xrestop doesn't show much more. As of this writing I'm currently getting this error and cannot open any more processes. `lsof -U` lists 203 items (mostly chromium, but I don't think that's the problem here), but `sudo ls /proc/2541/fd` has 259 items (2541 is the pid of Xorg.bin.)
Now here's the thing, if I switch between my two x servers with ctrl+alt+f1/f2 (this works even if tty2 is a framebuffer) the number of items in /proc/2541/fd increases by one. Indeed if I run `sudo ls -p 2541` there's a new entry, /dev/dri/card0
I think that every time I switch, X re-opens my graphics card, but never closes the old connection. the number of items lsof -U doesn't change when I do this, so none of my programs are to blame, this is just X.
Because there are a lot of old connections floating around, I'm guessing the number of clients X can have is severely limited. I think this is why I'm getting these errors.
Not sure if this is a DRI extension error, saw the dri in /dev/dri/card0 and assumed.
I just updated three days ago too. Still have this problem.
~$ Xorg.bin -version
X.Org X Server 1.16.2
Release Date: 2014-11-10
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.17.2-1-ARCH x86_64
Current Operating System: Linux blackle-thinkpad 3.17.3-3-ck #1 SMP PREEMPT Tue Nov 18 16:50:56 EST 2014 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux-ck root=UUID=65d91862-d03e-4b93-b52c-6dae55b39a97 ro nox2apic rcutree.rcu_idle_gp_delay=1 init=/usr/lib/systemd/systemd
Build Date: 10 November 2014 07:52:13PM
Current version of pixman: 0.32.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.https://gitlab.freedesktop.org/xorg/xserver/-/issues/210regression: X segfaults with xf86-video-intel-2.99.912 and DRI_PRIME (with ra...2019-07-30T17:37:15ZBugzilla Migration Userregression: X segfaults with xf86-video-intel-2.99.912 and DRI_PRIME (with radeon)## Submitted by Jan Buecken
Assigned to **Xorg Project Team**
**[Link to original bug (#80001)](https://bugs.freedesktop.org/show_bug.cgi?id=80001)**
## Description
Created attachment 101006
xorg log after segfault
Hello,
after u...## Submitted by Jan Buecken
Assigned to **Xorg Project Team**
**[Link to original bug (#80001)](https://bugs.freedesktop.org/show_bug.cgi?id=80001)**
## Description
Created attachment 101006
xorg log after segfault
Hello,
after update from
xf86-video-intel-2.21.15
to
xf86-video-intel-2.99.912
(with xorg-server-1.15.0)
the X server segfaults if I try to use dri_prime.
I run
DRI_PRIME=1 glxgears
and X restarts. Everything is working fine with xf86-video-intel-2.21.15
Setup:
xf86-video-intel-2.99.912
xorg-server-1.15.0
xf86-video-ati-7.3.0
A xorg log that shows a backtrace is attached.
**Attachment 101006**, "xorg log after segfault":
[Xorg.0.log.old](/uploads/b535711b407ee0dd1c1106c9d4864d30/Xorg.0.log.old)https://gitlab.freedesktop.org/xorg/xserver/-/issues/202[SteamOS][HSW GT3e] VT-switch causes “no responsive” on graph interface by 3-...2018-12-13T18:31:57ZBugzilla Migration User[SteamOS][HSW GT3e] VT-switch causes “no responsive” on graph interface by 3-6 times## Submitted by meng
Assigned to **Xorg Project Team**
**[Link to original bug (#77556)](https://bugs.freedesktop.org/show_bug.cgi?id=77556)**
## Description
System Environment:
--------------------------
Mesa: (master)ee2bcf3...## Submitted by meng
Assigned to **Xorg Project Team**
**[Link to original bug (#77556)](https://bugs.freedesktop.org/show_bug.cgi?id=77556)**
## Description
System Environment:
--------------------------
Mesa: (master)ee2bcf38a4c8930d8f9cecfac580030a45c41dae
Xserver: (master)xorg-server-1.15.99.902-2-g3028ae6c9aa37168e249e0d8
Xf86_video_intel: (master)2.99.911-58-gf9a279b2dc8417b6504478ac96514125d6136523 Kernel: (drm-intel-nightly)git-cf8c74
Bug detailed description:
----------------------------
VT-switch may cause “no responsive” on graph interface by 3-6 times.
“no responsive”is that screen seems to be frozen, mouse and keyboard can’t work. In the meantime, console is OK. Please see dmesg log and Xorg.0.log.
Reproduce steps:
-------------------------
1. start system
2. VT-switch by 3-6 timeshttps://gitlab.freedesktop.org/xorg/xserver/-/issues/209Xserver not responding to client's request2018-12-13T18:32:24ZBugzilla Migration UserXserver not responding to client's request## Submitted by Lionel Landwerlin
Assigned to **Xorg Project Team**
**[Link to original bug (#65119)](https://bugs.freedesktop.org/show_bug.cgi?id=65119)**
## Description
While running gnome-shell I a few lockup every day.
Every t...## Submitted by Lionel Landwerlin
Assigned to **Xorg Project Team**
**[Link to original bug (#65119)](https://bugs.freedesktop.org/show_bug.cgi?id=65119)**
## Description
While running gnome-shell I a few lockup every day.
Every time I attach gdb to see where the shell is blocked, I get this backtrace :
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff1a3fe000
0x00007f413780e1bd in poll () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
```
(gdb) bt
#0 0x00007f413780e1bd in poll ()
at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f41354881c2 in ?? ()
from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2 0x00007f4135489697 in ?? ()
from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007f41354898bb in xcb_wait_for_reply ()
from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4 0x00007f413a135109 in _XReply ()
from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007f412ab64100 in DRI2GetMSC (dpy=0x13ea5a0, drawable=23068699,
ust=ust@entry=0x7fff1a3293e8, msc=msc@entry=0x7fff1a3293f0,
sbc=sbc@entry=0x7fff1a3293f8) at dri2.c:589
#6 0x00007f412ab62818 in dri2DrawableGetMSC (psc=<optimized out>,
pdraw=<optimized out>, ust=0x7fff1a329448, msc=0x7fff1a329450,
sbc=0x7fff1a329458) at dri2_glx.c:419
#7 0x00007f413b8893d1 in _cogl_winsys_wait_for_vblank (
onscreen=onscreen@entry=0x23d8620) at ./winsys/cogl-winsys-glx.c:1484
#8 0x00007f413b8899f2 in _cogl_winsys_onscreen_swap_region (
onscreen=0x23d8620, user_rectangles=<optimized out>,
n_rectangles=<optimized out>) at ./winsys/cogl-winsys-glx.c:1688
#9 0x00007f413b87e83f in cogl_onscreen_swap_region (onscreen=0x23d8620,
rectangles=0x7fff1a3295e0, n_rectangles=1) at ./cogl-onscreen.c:234
#10 0x00007f413c133688 in ?? ()
from /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0
#11 0x00007f413c19aaf3 in ?? ()
from /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0
#12 0x00007f413c1805f8 in ?? ()
from /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0
#13 0x00007f4137d42f25 in g_main_dispatch (context=0x13bad60)
at /tmp/buildd/glib2.0-2.36.1/./glib/gmain.c:3054
#14 g_main_context_dispatch (context=context@entry=0x13bad60)
at /tmp/buildd/glib2.0-2.36.1/./glib/gmain.c:3630
#15 0x00007f4137d43268 in g_main_context_iterate (context=0x13bad60,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
---Type <return> to continue, or q <return> to quit---
at /tmp/buildd/glib2.0-2.36.1/./glib/gmain.c:3701
#16 0x00007f4137d436da in g_main_loop_run (loop=0x13bd640)
at /tmp/buildd/glib2.0-2.36.1/./glib/gmain.c:3895
#17 0x00007f4140b51ba1 in meta_run () from /usr/lib/libmutter.so.0
#18 0x0000000000401f59 in ?? ()
#19 0x00007f4137752a55 in __libc_start_main (main=0x401c40, argc=1,
ubp_av=0x7fff1a329a08, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fff1a3299f8)
at libc-start.c:260
#20 0x0000000000402059 in ?? ()
```
I'm using xserver-xorg 7.7 and mesa 8.0.5 on Debian unstable.
Version: 7.7 (2012.06)https://gitlab.freedesktop.org/xorg/xserver/-/issues/207Performance degrades after several glXMakeCurrent/glXMakeContextCurrent calls2018-12-13T18:32:18ZBugzilla Migration UserPerformance degrades after several glXMakeCurrent/glXMakeContextCurrent calls## Submitted by Steve
Assigned to **Xorg Project Team**
**[Link to original bug (#55675)](https://bugs.freedesktop.org/show_bug.cgi?id=55675)**
## Description
Created attachment 68138
Modified isosurf sample from wxWidgets
It see...## Submitted by Steve
Assigned to **Xorg Project Team**
**[Link to original bug (#55675)](https://bugs.freedesktop.org/show_bug.cgi?id=55675)**
## Description
Created attachment 68138
Modified isosurf sample from wxWidgets
It seems that on Sandybridge chipsets performance degrades after making several calls to glXMakeCurrent and/or glXMakeContextCurrent calls and Xorg process will slowly ramp up CPU. This issue has been repeated with Ubuntu 10.04 running Mesa 7.10 drivers, Ubuntu 12.04 running Mesa 8.x drivers, and Ubuntu 12.04 running Mesa 9.1-devel drivers.
If you create multiple contexts and change between them this problem doesn't seem to happen. It seems to only happen if you have one context and change between several different drawables.
I've modified a wxWidgets sample in order to demonstrate and reproduce the problem. Note that in my code I call SwapBuffers, but this is not necessary to reproduce the issue.
**Attachment 68138**, "Modified isosurf sample from wxWidgets":
[isosurf.cpp](/uploads/1d240c02d94ca640ca9145f5614cbc06/isosurf.cpp)
Version: git