Bug 100708 - Trine 2 doesn't start on radeonsi on mesa 17
Summary: Trine 2 doesn't start on radeonsi on mesa 17
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: 17.0
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL: https://bugs.mageia.org/show_bug.cgi?...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-18 12:35 UTC by Nikita Krupenko
Modified: 2018-08-20 04:49 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikita Krupenko 2017-04-18 12:35:29 UTC
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
Comment 1 Michel Dänzer 2017-04-19 03:56:52 UTC
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?
Comment 2 Nikita Krupenko 2017-04-19 19:03:38 UTC
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.
Comment 3 Michel Dänzer 2017-04-20 01:37:52 UTC
Marek, any ideas?

Nikita, can you try if it still happens with Mesa Git master?
Comment 4 Marek Olšák 2017-04-20 09:46:40 UTC
That commit is unlikely to cause any issues with X11.
Comment 5 Nikita Krupenko 2017-04-20 10:18:45 UTC
(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
Comment 6 Vedran Miletić 2017-04-20 10:21:24 UTC
(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?
Comment 7 Nikita Krupenko 2017-04-21 15:34:52 UTC
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.
Comment 8 Nikita Krupenko 2017-05-05 19:53:45 UTC
How about revert that commit?
Comment 9 Kamil Páral 2017-07-13 17:43:53 UTC
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
Comment 10 Nicholas Miell 2017-12-08 18:32:06 UTC
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).
Comment 11 Nicholas Miell 2017-12-08 18:46:09 UTC
(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.
Comment 12 Ray Strode [halfline] 2017-12-08 19:03:40 UTC
> #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.
Comment 13 Nicholas Miell 2017-12-08 19:42:03 UTC
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.