From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 101731] System freeze with AMDGPU when playing The Witcher 3
Date: Sun, 09 Jul 2017 17:59:32 +0000
Message-ID:
Bug ID
101731
Summary
System freeze with AMDGPU when playing The Witcher 3
Product
Mesa
Version
17.1
Hardware
x86-64 (AMD64)
OS
Linux (All)
Status
NEW
Severity
major
Priority
medium
Component
Drivers/Gallium/radeonsi
Assignee
dri-devel@lists.freedesktop.org
Reporter
murks@tuxfamily.org
QA Contact
dri-devel@lists.freedesktop.org
Created attachmen=
t 132575 [details]
Save Game to reproduce the bug
Hi there.
I get reproducable system freezes when playing The Witcher 3. The save game
that lets me reproduce this quickly is attached (requires The Witcher 3 with
all Add-Ons).
I've reported this bug it wine first but as far as we could firgure out it =
is
more likely a bug in mesa. You can find the wine bug report here:
https://bugs.wi=
nehq.org/show_bug.cgi?id=3D43273
I'm using an AMD RX 460 on Arch Linux with Mesa 17.1.4.
I don't know how to debug this further since I can't do anything as soon as=
the
freeze happens. The game music keeps playing. Sometimes Ctrl+Alt+FX lets me=
see
the TTY, but nothing reacts afterwards and the game music stops.
There is nothing possibly related in the journal or Xorg logs.
Created attachment 132576 [details]
glxinfo output
Try doing an apitrace and post it here. Like this: > WINEPREFIX=3D/path/to/prefix apitrace trace wine= witcher3.exe Then replaying the trace should hang your computer: > apitrace replay wine64-preloader.trace= pre>
Do you have any suggestion on how to get this trace within rea= sonable time? It usually just takes me a few seconds to trigger the bug. As it stands I g= et about two frames per minute, which means it will take me hours to get the trace. I tried lowering resolution and all gfx settings as far as possible (I still get the bug), but that helped only a little bit.
I've tried this now for about 2 hours and have a 50 GB trace f= ile. No freeze though. I guess it was about 30 seconds of running around in in-game time, which is usually enough to trigger the freeze. I might have been unlucky or it might not happen in apitrace. Maybe someone else has more luck. I might try once more to install the amdgpu-pro drivers and see whether it happens there as well. I'm open to other suggestions.
I've managed to install amdgpu-pro and that has brought me a b= it closer to narrowing this down. Just for reference, the software versions are amdgpu-p= ro 17.10.401251-2 and related packages (https= ://aur.archlinux.org/packages/?O=3D0&K=3Damdgpu), mesa-noglvnd 17.1= .4, xorg-server 1.18.4-1. With amdgpu-pro I could narrow the freeze down to a specific option in the game: nvidia hairworks. With that option disabled I do not get the freeze. = As soon as it is enabled and a game loaded the machine freezes. I've used this to get a apitrace quickly and I have one with just 1.1 GB. However, replaying it does not produce the freeze. Maybe the actual freeze trigger didn't make it into the file. I'll provide you the file if you tell= me how. I do have a lot of warnings and errors on console when I replay that file (= see console_out). Nvidia hairworks does not trigger the freeze with amdgpu, but it does so immediately with amdgpu-pro. amdgpu triggers the freeze seemingly randomly,= at least in Velen, not in White Orchard. amdgpu-pro does not trigger the freez= e in Velen (unless hairworks is enabled of course). Since both amdgpu and amdgpu-pro use mesa and the non-mesa proprietary nvid= ia driver does not trigger this bug it is likely something in mesa. I hope the above helps to track it down.
Created attachment 132604 [details]
console output when replaying the apitrace of a crash
(In reply to Philipp =C3=9Cberbacher from comment #5)=20 > I've used this to get a apitrace quickly and I h= ave one with just 1.1 GB. > However, replaying it does not produce the freeze. Maybe the actual fr= eeze > trigger didn't make it into the file. I'll provide you the file if you= tell > me how. You can try this service: https://upload= files.io It's time limited though, but should be enough for 30 days.
I noticed, when I set graphics settings to minimum, this freez= e doesn't happen (or at least didn't happen to me so far).
Created attachment 132626 [details]=
a>
The Witcher 3 crash save (GOG/GOTY version).
With latest Mesa built from source, it now consistently crashes for me on V=
elen
checkpoint save, on max settings (hairworks disabled).
OpenGL renderer string: AMD Radeon RX 480 Graphics (AMD POLARIS10 / DRM 3.1=
0.0
/ 4.11.0-1-amd64, LLVM 4.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.0-devel
(git-f7e78abdf4)
(In reply to Shmerl from comment #10) > Created attachment 132626 [details] > The Witcher 3 crash save (GOG/GOTY version). >=20 > With latest Mesa built from source, it now consistently crashes for me= on > Velen checkpoint save, on max settings (hairworks disabled). >=20 > OpenGL renderer string: AMD Radeon RX 480 Graphics (AMD POLARIS10 / DRM > 3.10.0 / 4.11.0-1-amd64, LLVM 4.0.1) > OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.0-dev= el > (git-f7e78abdf4) That's wonderfull (in a way). Maybe you can get an apitrace from that?
May be I'm doing somethin wrong. I tried to record a trace (us= ing Mesa built from source which I load using a script). I recorded a small amount - starting menu first, but when replaying it, I g= et black screen and such: 2127496 @3 glXSwapBuffersMscOML(dpy =3D 0x7cb2f3b0, drawable =3D 121634= 929, target_msc =3D 0, divisor =3D 0, remainder =3D 0) =3D 1228 2127496: warning: unsupported glXSwapBuffersMscOML call 2128642 @3 glXSwapBuffersMscOML(dpy =3D 0x7cb2f3b0, drawable =3D 121634= 929, target_msc =3D 0, divisor =3D 0, remainder =3D 0) =3D 1229 2128642: warning: unsupported glXSwapBuffersMscOML call 2130677 @3 glXSwapBuffersMscOML(dpy =3D 0x7cb2f3b0, drawable =3D 121634= 929, target_msc =3D 0, divisor =3D 0, remainder =3D 0) =3D 1230 2130677: warning: unsupported glXSwapBuffersMscOML call 2131778 @3 glXSwapBuffersMscOML(dpy =3D 0x7cb2f3b0, drawable =3D 121634= 929, target_msc =3D 0, divisor =3D 0, remainder =3D 0) =3D 1231 2131778: warning: unsupported glXSwapBuffersMscOML call 2133839 @3 glXSwapBuffersMscOML(dpy =3D 0x7cb2f3b0, drawable =3D 121634= 929, target_msc =3D 0, divisor =3D 0, remainder =3D 0) =3D 1232 2133839: warning: unsupported glXSwapBuffersMscOML call 2136933 @3 glXCreateWindow(dpy =3D 0x7cb2f3b0, config =3D 0x7cc82380, w= in =3D 127926276, attribList =3D {}) =3D 121634992 2136933: warning: unsupported glXCreateWindow call Rendered 0 frames in 6.86555 secs, average of 0 fps So not sure if full trace would be useful until it will actually show anyth= ing.
(In reply to Shmerl from comment #12) > May be I'm doing somethin wrong. I tried to reco= rd a trace (using Mesa built > from source which I load using a script). >=20 > I recorded a small amount - starting menu first, but when replaying it= , I > get black screen and such: >=20 > 2127496 @3 glXSwapBuffersMscOML(dpy =3D 0x7cb2f3b0, drawable =3D 1= 21634929, > target_msc =3D 0, divisor =3D 0, remainder =3D 0) =3D 1228 > 2127496: warning: unsupported glXSwapBuffersMscOML call > 2128642 @3 glXSwapBuffersMscOML(dpy =3D 0x7cb2f3b0, drawable =3D 1= 21634929, > target_msc =3D 0, divisor =3D 0, remainder =3D 0) =3D 1229 > 2128642: warning: unsupported glXSwapBuffersMscOML call > 2130677 @3 glXSwapBuffersMscOML(dpy =3D 0x7cb2f3b0, drawable =3D 1= 21634929, > target_msc =3D 0, divisor =3D 0, remainder =3D 0) =3D 1230 > 2130677: warning: unsupported glXSwapBuffersMscOML call > 2131778 @3 glXSwapBuffersMscOML(dpy =3D 0x7cb2f3b0, drawable =3D 1= 21634929, > target_msc =3D 0, divisor =3D 0, remainder =3D 0) =3D 1231 > 2131778: warning: unsupported glXSwapBuffersMscOML call > 2133839 @3 glXSwapBuffersMscOML(dpy =3D 0x7cb2f3b0, drawable =3D 1= 21634929, > target_msc =3D 0, divisor =3D 0, remainder =3D 0) =3D 1232 > 2133839: warning: unsupported glXSwapBuffersMscOML call > 2136933 @3 glXCreateWindow(dpy =3D 0x7cb2f3b0, config =3D 0x7cc823= 80, win =3D > 127926276, attribList =3D {}) =3D 121634992 > 2136933: warning: unsupported glXCreateWindow call > Rendered 0 frames in 6.86555 secs, average of 0 fps >=20 > So not sure if full trace would be useful until it will actually show > anything. I've gotten the black screen in my replay-attempts too, but I guess that is normal. Otherwise the replay would require all the textures and whatnot. Does your replay trigger the freeze (mine did not)? Maybe you can upload the trace?
I didn't get to the freeze point in the replay, but I remember= in the past, when I recorded a trace and replayed it, it actually showed images (i.e. vi= deo like). So I suppose something is wrong with my tracing. But I can record a crash trace just in case anyway.
Interestingly, when I record a trace, and it reaches the point= where it's supposed to freeze, it doesn't. I.e. the tracing somehow prevents it from happening.
I finally came around to uploading this trace (should be up fo= r 30 days). Remember that it was with amdgpu-pro and replaying did not cause the freeze= . I hope it helps anyway. https://ufile.io/pb1m8
Just for the reference, the freeze doesn't happen to me anymor= e, in a newer configuration. See https:/= /bugs.winehq.org/show_bug.cgi?id=3D43273#c12
Actually, I just experienced the freeze bug again. I guess it'= s somehow random, and it's not truly gone :(
What | Removed | Added |
---|---|---|
Version | 17.1 | git |
(In reply to Lennard from comment #19) > I can confirm this happens with radeonsi too Well, most previous reports were about radeonsi.
Created attach=
ment 133134 [details]
dmesg when freeze almost happened
I was able to save my system by switching around TTYs somehow, checked dmesg
and got this.
Using an R7 260X with radeonsi