Bug 89377

Summary:	[radeonsi] "Hand of Fate" is stuck on SIGPWR/SIGXCPU after start
Product:	Mesa	Reporter:	Kai <kai>
Component:	Drivers/Gallium/radeonsi	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED NOTOURBUG	QA Contact:	Default DRI bug account <dri-devel>
Severity:	normal
Priority:	medium
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	77449

Description Kai 2015-03-01 16:48:37 UTC

The Unity3D-based (Mono) game "Hand of Fate" is stuck on a black screen after the initial static screens (logos) and just the music is playing. If I attach GDB to the game I see SIGPWR being received by the game, pressing c just get's me another such signal, sometimes the endless SIGPWR stream is broken by a SIGXCPU or two.

This sounds oddly reminiscent of bug #60929, but I'm not seeing this with any other Mono-based game besides "Hand of Fate". And since I haven't managed to start the game with R600_LLVM=0, I can't verify, whether this is the same bug or a different one.

Please also note, that there seems to be a similar issue (ie. same effect) with this game, that can be fixed by rebooting most of the time, if I go by the forums. See e.g. <http://steamcommunity.com/app/266510/discussions/0/617329150700428644/#c617329150701149465>, where the developer recommends this procedure. Not sure, if those two are related.

My current stack (Debian testing as a base) is:
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/050bf75c8b
libdrm: Git:master/1f73578df3
LLVM: SVN:trunk/r230209 (3.7 devel)
X.Org: Git:master/xorg-server-1.17.1
Linux: 3.19.0
Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
> 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
> c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
> 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
> c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
> 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
> ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
> 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
> 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
libclc: Git:master/5cd2688a9f
DDX: Git:master/b8ec9ed4fe

Let me know, if you need something else.

Comment 1 smoki 2015-03-01 21:15:57 UTC

(In reply to Kai from comment #0)
> 
> Let me know, if you need something else.

 Xorg.0.log and glxinfo output.

 Because it must be specific to resolution or you might miss s3tc extension, or such...

 Or also because it is unity game, try to manually change prefs, look into logs, etc... from the game, those are usually stored in game dir or in ~/.config/unity3d/blah_blah , etc...

Comment 2 Kai 2015-03-02 11:02:46 UTC

(In reply to smoki from comment #1)
> (In reply to Kai from comment #0)
> > 
> > Let me know, if you need something else.
> 
>  Xorg.0.log and glxinfo output.

Nope. glxinfo would only be helpful, if you want to suggest I'm not using radeonsi and falling back to e.g. llvmpipe. Xorg.0.log would have been posted (and mentioned), if something would have been logged there, after starting the game (same goes for the obvious other places like dmesg).
 
>  Because it must be specific to resolution or you might miss s3tc extension,
> or such...

No. Have a look at the referenced bug, and you can see that this assumption is baseless. A missing S3TC extension might lead to textureless models, but most likely not to a SIGPWR/SIGXCPU. Please don't just throw random stuff in bug reports, keep the noise down. My reply here was inflated unnecessarily.

But since yesterday I've been able to find, that the game generating "Got a bad hardware address length for an AF_PACKET 16 8" is a known bug with Unity/Mono and some games express the same behaviour (black screen). I'm going to close this bug for the moment and open it later, if the developer fixed the issue and this problem persists.

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.