Bug 93801 - GRID Autosport hang on logo (startup)
Summary: GRID Autosport hang on logo (startup)
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-20 20:04 UTC by Maxim Sheviakov
Modified: 2016-02-17 07:50 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Log from gdb (92.27 KB, text/plain)
2016-02-16 09:27 UTC, Maxim Sheviakov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maxim Sheviakov 2016-01-20 20:04:11 UTC
On GCN1.0 chip (Trinidad - Radeon R7 370) there is a hang at GRID logo at the start of the game. The issue, however, doesn't appear at GCN >= 1.1 chips - the game runs out-of-the-box there. The problem is connected with this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=93352
as the fix ("LANG=C LD_PRELOAD="../lib/x86_64/libtcmalloc_minimal.so:${LD_PRELOAD}" %command%" in run params in Steam) from there makes the game work normally. I'd bet that it is RadeonSI-specific, as there were similar reports from other GCN1.0-chips owners.
Comment 1 Maxim Sheviakov 2016-01-20 20:06:26 UTC
I'm using Arch Linux x64 with Mesa 11.1.1 + lib32-Mesa 11.1.1 compiled from source with latest stable GCC and LLVM 3.7.1 (both normal and multilib). I have testing repositories enabled. No git packages are used, Linux is 4.4-zen.
Comment 2 Michel Dänzer 2016-01-21 02:24:27 UTC
What are the symptoms of the hang? If the GRID process still exists, does killing it restore a working desktop? Can you attach gdb to the GRID process and attach the output of "thread apply all bt full" when it hangs?
Comment 3 José Suárez 2016-01-21 09:33:58 UTC
Can you try with "LC_ALL=C" instead of "LANG=C"? For me the latter did not work (http://steamcommunity.com/app/255220/discussions/0/558754260336036448/#c494631967654246615), while I can play the game correctly (and with quite good performance, BTW) with the former. I'm using a Radeon HD 7870 with almost git mesa.
Comment 4 Maxim Sheviakov 2016-01-21 12:14:11 UTC
(In reply to José Suárez from comment #3)
> Can you try with "LC_ALL=C" instead of "LANG=C"? For me the latter did not
> work
> (http://steamcommunity.com/app/255220/discussions/0/558754260336036448/
> #c494631967654246615), while I can play the game correctly (and with quite
> good performance, BTW) with the former. I'm using a Radeon HD 7870 with
> almost git mesa.

It worked. However, I've noticed some kind of a performance drop, but that doesn't actually matter, as the difference was about -5FPS.
Comment 5 Maxim Sheviakov 2016-01-21 12:17:55 UTC
(In reply to Michel Dänzer from comment #2)
> What are the symptoms of the hang? If the GRID process still exists, does
> killing it restore a working desktop? Can you attach gdb to the GRID process
> and attach the output of "thread apply all bt full" when it hangs?

Umm, the game doesn't hang the system. It's about the game's process not to respond at all - I can simply go to desktop and kill the process. I don't think that gdb attachment would help either, as the game is likely trying to load some files that it can't find, and then it hangs, so log would probably contain only "foo.bar: not found".
Comment 6 José Suárez 2016-01-21 15:13:38 UTC
(In reply to Maxim Sheviakov from comment #5)
> (In reply to Michel Dänzer from comment #2)
> > What are the symptoms of the hang? If the GRID process still exists, does
> > killing it restore a working desktop? Can you attach gdb to the GRID process
> > and attach the output of "thread apply all bt full" when it hangs?
> 
> Umm, the game doesn't hang the system. It's about the game's process not to
> respond at all - I can simply go to desktop and kill the process. I don't
> think that gdb attachment would help either, as the game is likely trying to
> load some files that it can't find, and then it hangs, so log would probably
> contain only "foo.bar: not found".

For your information, Feral currently have a semi-open beta of Grid which among other things resolves the hang problem. In order to be able to access the beta you need to contact their customer support and they will give the key to you straight away.

I'm running plain vanilla, so I can't tell if it solves the problem you are reporting.
Comment 7 Michel Dänzer 2016-01-27 07:11:00 UTC
(In reply to Maxim Sheviakov from comment #5)
> Umm, the game doesn't hang the system. It's about the game's process not to
> respond at all - I can simply go to desktop and kill the process. I don't
> think that gdb attachment would help either, [...]

Of course it would; it would show us whether it's hanging in game code or driver code. From José's comments it sounds like it's likely the former though.
Comment 8 Maxim Sheviakov 2016-01-27 07:16:33 UTC
Okay. I will test it with a debugger + beta (if I'm lucky) one I complete my Gentoo setup.
Comment 9 Maxim Sheviakov 2016-02-15 18:11:28 UTC
(In reply to Michel Dänzer from comment #7)
> (In reply to Maxim Sheviakov from comment #5)
> > Umm, the game doesn't hang the system. It's about the game's process not to
> > respond at all - I can simply go to desktop and kill the process. I don't
> > think that gdb attachment would help either, [...]
> 
> Of course it would; it would show us whether it's hanging in game code or
> driver code. From José's comments it sounds like it's likely the former
> though.

This is the output: http://pastebin.com/ZVYp8HcQ
Comment 10 Michel Dänzer 2016-02-16 00:36:55 UTC
(In reply to Maxim Sheviakov from comment #9)
> This is the output: http://pastebin.com/ZVYp8HcQ

Please attach files here directly instead of referencing external sites.

After attaching to the process, please run "thread apply all bt full" at the gdb prompt to get the backtrace.
Comment 11 Maxim Sheviakov 2016-02-16 09:27:30 UTC
Created attachment 121779 [details]
Log from gdb

(In reply to Michel Dänzer from comment #10)
> Please attach files here directly instead of referencing external sites.
Okay, sorry.

> After attaching to the process, please run "thread apply all bt full" at the
> gdb prompt to get the backtrace.
Attaching the file, log collected with
~/> gdb > gdblog
%commands%
Comment 12 Maxim Sheviakov 2016-02-16 10:02:53 UTC
I also can't get native runtime working. After doing
> cd ~/.local/share/Steam/ubuntu12_32
> LD_LIBRARY_PATH=".:${LD_LIBRARY_PATH}" ldd $(file *|sed '/ELF/!d;s/:.*//g')|grep 'not found'|sort|uniq

I got the output containing
> libdbus-glib-1.so.2 => not found
> libgconf-2.so.4 => not found
> libnm-glib.so.4 => not found
> libnm-util.so.2 => not found
> libudev.so.0 => not found

Maybe that's an issue, but I don't think so - on my previous Archlinux installation the game wouldn't start with all those libraries present. Basically, my Linux installations' configurations were mostly the same.
Comment 13 Michel Dänzer 2016-02-17 01:04:04 UTC
There's no trace of the driver being involved in the hanging state. Based on that and José's comments, let's assume that this is a game bug.
Comment 14 Maxim Sheviakov 2016-02-17 07:50:02 UTC
(In reply to Michel Dänzer from comment #13)
> There's no trace of the driver being involved in the hanging state. Based on
> that and José's comments, let's assume that this is a game bug.

Damn, that's interesting. I will try to attach gdb to game running with that line in its Steam options and search for anything different.


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.