I have a laptop with AMD A8-5557M APU (Radeon HD 8550G, r600) and discrete videocard Radeon HD 8750M (radeonsi). I also have a monitor connected via a hdmi and use it as main screen. I use PRIME to play a game: $ xrandr --setprovideroffloadsink 0x41 0x78 $ DRI_PRIME=1 steam With DRI drivers version 12 it works fine, but if I update it to the recent one (17), the game doesn't start: when I click on start button in the launcher, the screen became black for a moment and the game exits. There is no unusual messages in the console. I found, that if I replace /usr/lib/dri/radeonsi_dri.so with the old one, the game works. With the integrated video (r600) it works fine on all versions. I reported also this to the distribution bug tracker [1], but seems this is an upstream bug in the radeonsi driver. [1] https://bugs.mageia.org/show_bug.cgi?id=20632
From the Steam output referenced in the downstream bug report: libGL: pci id for fd 75: 1002:6600, driver radeonsi libGL: OpenDriver: trying /usr/lib/dri/tls/radeonsi_dri.so libGL: OpenDriver: trying /usr/lib/dri/radeonsi_dri.so libGL: Can't open configuration file /home/nekit/.drirc: No such file or directory. libGL: Can't open configuration file /home/nekit/.drirc: No such file or directory. libGL: Using DRI3 for screen 0 XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 170 requests (170 known processed) with 1 events remaining. Game removed: AppID 35720 "Trine 2", ProcID 3765 It's likely (though not 100% certain) that the game aborts due to the X11 protocol error. Unfortunately, it could be relatively tricky to find out what triggers that error. I don't suppose you can bisect Mesa, or at least narrow down the upstream release where it first happened?
I haven't tested with 12 and 13 version (steam always crashes on start if I use /usr/lib/dri/radeonsi_dri.so from that build, may be because I use configured flag --with-egl-platforms=drm - configure failed otherwise). But, I found, that it works on 17 branch and found the commit, after which it doesn't: https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.0&id=6d2c4e940e5f6d80c94cc0ee9d26fee50202a4e0 After that commit, sometimes Trine 2 exits immediately, sometimes I see black screen for a several seconds and it then exits with the following message: [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. trine2_linux_32bit: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Marek, any ideas? Nikita, can you try if it still happens with Mesa Git master?
That commit is unlikely to cause any issues with X11.
(In reply to Michel Dänzer from comment #3) > Nikita, can you try if it still happens with Mesa Git master? It doesn't compile: Requested 'libdrm >= 2.4.79' but version of libdrm is 2.4.75 Requested 'libdrm_amdgpu >= 2.4.79' but version of libdrm_amdgpu is 2.4.75
(In reply to Nikita Krupenko from comment #5) > Requested 'libdrm >= 2.4.79' but version of libdrm is 2.4.75 > Requested 'libdrm_amdgpu >= 2.4.79' but version of libdrm_amdgpu is 2.4.75 Can you ask Mageia to upgrade libdrm?
I built and installed packages with newer libdrm. Checked on master branch - same behaviour. And I still see either message like this one: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 175 requests (175 known processed) with 28 events remaining. Game removed: AppID 35720 "Trine 2", ProcID 1437 either this: trine2_linux_32bit: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. or no message at all and steam just crash.
How about revert that commit?
I can confirm this problem with Radeon 270. I've seen this error: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 178 requests (178 known processed) with 4 events remaining. or this error: XIO: fatal IO error 2 (No such file or directory) on X server ":0" after 188 requests (188 known processed) with 8 events remaining. mesa-dri-drivers-17.2.0-0.69.git7250cba.fc26.x86_64 mesa-dri-drivers-17.2.0-0.69.git7250cba.fc26.i686 libdrm-2.4.81-1.fc26.x86_64 libdrm-2.4.81-1.fc26.i686 Fedora 26
Trine 2 uses an SDL 1.3, which is an ancient predecessor to SDL 2. SDL 1.3 disables the screensaver by forking and running gnome-screensaver-command --inhibit. gnome-screensaver-command doesn't exist on modern Linux distros, so the exec fails and the child calls exit(). The child then SIGSEGVs with the following stack trace: #0 __pthread_join (threadid=3571178304, thread_return=thread_return@entry=0xffffb528) at pthread_join.c:45 #1 0xd942f463 in thrd_join (res=0x0, thr=<optimized out>) at ../../include/c11/threads_posix.h:336 #2 util_queue_killall_and_wait (queue=queue@entry=0xba1449c) at u_queue.c:305 #3 0xd942f4e7 in atexit_handler () at u_queue.c:51 #4 0xf6cbe8d3 in __run_exit_handlers (status=2, listp=0xf6e483fc <__exit_funcs>, run_list_atexit=true, run_dtors=true) at exit.c:83 #5 0xf6cbe931 in __GI_exit (status=2) at exit.c:105 #6 0xf7d2647e in gnome_screensaver_disable () from ./lib/lib32/libSDL-1.3.so.0 #7 0xf7d2656b in X11_SuspendScreenSaver () from ./lib/lib32/libSDL-1.3.so.0 #8 0xf7d1b32e in SDL_DisableScreenSaver () from ./lib/lib32/libSDL-1.3.so.0 #9 0xf7c61081 in SetupScreenSaver () from ./lib/lib32/libSDL-1.3.so.0 #10 0xf7c6155f in SDL_SetVideoMode () from ./lib/lib32/libSDL-1.3.so.0 #11 0x08bf7941 in ?? () #12 0x08c3795e in ?? () #13 0x08bbd3c1 in ?? () #14 0x08370b3d in ?? () #15 0x08d40640 in ?? () #16 0x080ae19d in ?? () #17 0xf6ca3823 in __libc_start_main (main=0x80ade50, argc=3, argv=0xffffbbb4, init=0x910f020, fini=0x910f090, rtld_fini=0xf7fe5900 <_dl_fini>, stack_end=0xffffbbac) at ../csu/libc-start.c:308 #18 0x080c2d7d in ?? () If you just leave the the child halted in gdb, the main game process appears to run normally (the game is perfectly playable).
(In reply to Marek Olšák from comment #4) > That commit is unlikely to cause any issues with X11. Looking at that commit, it doesn't appear to cope with the interaction between fork() & atexit() at all.
> #3 0xd942f4e7 in atexit_handler () at u_queue.c:51 > #4 0xf6cbe8d3 in __run_exit_handlers (status=2, listp=0xf6e483fc > <__exit_funcs>, run_list_atexit=true, run_dtors=true) at exit.c:83 > #5 0xf6cbe931 in __GI_exit (status=2) at exit.c:105 A program should never call exit() when exec() fails. Standard practice is _exit() in that case so the parent's atexit handlers don't get run.
You can work around this crash by either installing gnome-screensaver or putting #!/bin/sh exec /usr/bin/gnome-session-inhibit --inhibit-only "$@" in /usr/bin/gnome-screensaver-command
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.