Bug 94523

Summary:

GPU lockup HD 6950

Product:

xorg

Reporter:

Rin Rozen <alpherie>

Component:

Driver/Radeon

Assignee:

xf86-video-ati maintainers <xorg-driver-ati>

Status:

RESOLVED WORKSFORME

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

Version:

unspecified

Hardware:

x86-64 (AMD64)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
kern.log (GPU lockup in the end)	none
mesa errors	none
libGL debug output	none
shader dump + stdout	none
dmesg when lockup occurs	none

Description Rin Rozen 2016-03-13 16:00:15 UTC

Created attachment 122266 [details]
kern.log (GPU lockup in the end)

GPU lockup happens while playing game (WarThunder), making the whole system unresponsive for some time. The bug happens in one specific condition - when firing guns in game (it also causes some mesa errors). It does not depend whether game is played under wine with OpenGL render or linux version. 


Testing of linux version is currently blocked by bug https://bugs.freedesktop.org/show_bug.cgi?id=92850


Logs attached are kern.log, export LIBGL_DEBUG=verbose output, export MESA_DEBUG=1 output


Distro: Debian GNU/Linux stretch/sid
Kernel: 4.3.0-1-amd64 x86_64 (64 bit)
Desktop: LXDE (Openbox 3.6.1) 

Graphics card: Advanced Micro Devices [AMD/ATI] Cayman PRO [Radeon HD 6950]
Display Server: X.Org 1.18.1 driver: radeon
Resolution: 1920x1080@60.00hz
GLX Renderer: Gallium 0.4 on AMD CAYMAN (DRM 2.43.0, LLVM 3.7.1)
GLX Version: 3.0 Mesa 11.1.2

Comment 1 Rin Rozen 2016-03-13 16:01:22 UTC

Created attachment 122267 [details]
mesa errors

Comment 2 Rin Rozen 2016-03-13 16:02:27 UTC

Created attachment 122268 [details]
libGL debug output

Comment 3 Rin Rozen 2016-03-19 18:53:21 UTC

Compiled xf86-video-ati from master branch on git, problem is still there.

Comment 4 Jose P. 2016-05-30 22:25:42 UTC

Affects me too, but while my system responds to magic sysrq keys, it simply won't come back from a black screen, forcing me to reboot.

Comment 5 Rin Rozen 2016-06-15 19:42:43 UTC

Updated my system, the problem is still the same.

Kernel: 4.5.0-2-amd64 x86_64 (64 bit)
Display Server: X.Org 1.18.3
GLX Renderer: Gallium 0.4 on AMD CAYMAN (DRM 2.43.0, LLVM 3.8.0)
GLX Version: 3.0 Mesa 11.2.2

Comment 6 Jose P. 2016-07-14 17:31:59 UTC

Created attachment 125070 [details]
shader dump + stdout

Shaders dump + STDOUT from War Thunder, obtained by running:
LIBGL_DEBUG=verbose R600_DEBUG=fs,vs,gs,ps,cs,tcs,tes ~/.steam/steam/SteamApps/common/War\ Thunder/aces 1>shaders+stdout 2>&1
WARNING: the size of this file when uncompressed is 141MB.

Comment 7 Jose P. 2016-07-14 17:35:49 UTC

Created attachment 125071 [details]
dmesg when lockup occurs

Comment 8 Jose P. 2016-07-14 17:39:25 UTC

Forgot to mention my hardware: laptop HP dv6-6174la, GPU: AMD APU a6-3400m with integrated radeon hd 6520g, running Kubuntu 16.04 with the oibaf repo + Mesa 12.1 (released just a few days ago AFAIK).

Hope this helps.

Comment 9 i.kalvachev 2016-07-16 15:55:37 UTC

Could you try `export R600_DEBUG=nosb`?

This disables Shader Backend that optimizes the assembler code.
If this workarounds the problem, it would be useful to provide an
apitrace of the game that could reproduce your problem.

These may be related:
https://bugs.freedesktop.org/show_bug.cgi?id=86720
https://bugs.freedesktop.org/show_bug.cgi?id=93475
https://bugs.freedesktop.org/show_bug.cgi?id=94900

Comment 10 Rin Rozen 2016-07-18 20:17:30 UTC

(In reply to iive from comment #9)
> Could you try `export R600_DEBUG=nosb`?

I tried it and it helped. Will do more testing later.

Comment 11 Rin Rozen 2016-11-01 21:06:16 UTC

No lockup after update:

Kernel: 4.6.0-1-amd64 x86_64 (64 bit)
Display Server: X.Org 1.18.4 driver: radeon
GLX Renderer: Gallium 0.4 on AMD CAYMAN (DRM 2.43.0 / 4.6.0-1-amd64, LLVM 3.8.1)
GLX Version: 3.0 Mesa 12.0.3

Not sure if it was fixed somehow or just the game changed.

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.