| Bug ID | 93649 |
|---|---|
| Summary | [radeonsi] Graphics lockup while playing tf2 |
| Product | Mesa |
| Version | 11.0 |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | matthew@mjdsystems.ca |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 120925 [details]
Kernel dmesg around the time of the lockup.
After a period of time playing the latest version of TF2, my GPU locks up.
After the kernel tries to reset, the X becomes stuck and won't work. The rest
of the system is fine however. Sometimes, the GPU will reset successfully and
continue working, only to lockup later, eventually freezing X.
Hardware:
GPU: Gigabyte Radeon HD 7970 Ghz edition OC
CPU: AMD Phenom ii X6 1100T
MB: Asus Crosshair IV Formula
Software:
Mesa: 11.1.0
DRM: 2.4.65
LLVM: 3.7.0
X: 1.17.4
DDX: 7.6.1
Kernel: 4.3.3
I have a dmesg with debug turned on and a strace of X from around the time it
crashes (attached). I reduced the log file to the relevant bits, as they are
quite large. I'll retry with latest git, see if it helps anywhere.
Created attachment 120926 [details]
Strace of Xorg up to X freezing
FD 20 is the drm device node, and it freezes on ioctl 0xc020645d.
Created attachment 120927 [details]
Radeon blocked locks
Since X seemed blocked on an ioctl, I managed to get a list of all the blocked
locks, and found most of my taken locks were from GUI related programs who
would be doing GL things, and they are all blocked on a lock, including one
that is currently trying to reset my GPU.
I'm guessing there is a lock that is being grabbed twice, once when userspace
makes an ioctl, and again during the reset. I'll keep digging.
Also, I think this may be a duplicate of #90217, as both involve source games.
I'll leave this open for now, in case tf2 has a different trigger.
There is other logs: https://github.com/ValveSoftware/Source-1-Games/issues/1943
Created attachment 121242 [details] [review] This helps avoid a complete crash when a lockup occurs. Note this doesn't solve this bug, it just helps manage it.
Can confirm, I have either the same or a similar problem on my R9 390 (using radeon, with DPM disabled). It doesn't just crash X though, it completely locks up and I have to reboot to even use TTY. Happens after 10-20 mins of TF2. Running Arch Linux with everything up to date but no AUR packages, will post specifics later.
Created attachment 121293 [details] [review] Second patch to fix system lockup after gpu reset This is already taken accepted from the mailing list, including here for completeness. If anyone is experiencing this issue, can you please try with all of these patches applied? For now, X should die and restart without acceleration, but getting a dmesg out or restarting should be fine.
CPU: FX 8350 GPU: R9 390 MB: Asrock 970 Extreme4 Software: Kernel: 4.3.3-3-ARCH x86_64 Mesa: 11.1.1 DRM: 2.43.0 LLVM: 3.7.0 X: 1.18.0 As mentioned above, I get the crash with TF2, but *NOT* CS:GO.
Also, this could be a duplicate of bug #92912 - random lockups in TF2, all with radeon.
(In reply to pc.jago1337 from comment #8) > Also, this could be a duplicate of bug #92912 - random lockups in TF2, all > with radeon. I was asked to file this bug separately. Also that covers R600, a different GPU the GCN.
Same problem here on a fedora 23 GPU: HD 7970 CPU: Intel Core i7 950 Mesa 11.1.0 DRM 2.43.0 LLVM 3.7.0 kernel: 4.3.4 The logs are filed with "ring stalled" and GPU lock messages. I can send more logs if needed. radeon 0000:02:00.0: ring 3 stalled for more than 10249msec radeon 0000:02:00.0: GPU lockup (current fence id 0x000000000001e5f1 last fence id 0x000000000001e5f2 on ring 3) I've tried a different firmware (http://people.freedesktop.org/~agd5f/radeon_ucode/k/) which seemed to have helped other people with their own problem but it didn't help in my case. Does it makes sense to try to rollback to an older kernel?
| What | Removed | Added |
|---|---|---|
| Attachment #121242 is obsolete | 1 |
Created attachment 121578 [details] [review] New avoid lockup patch Latest version as posted to dri-devel. With these two patches, your system should no longer lockup forever. It will freeze the game for a moment, and X may die for other reasons. Now the underlying tf2 issue needs investigation.
I can say that it also affects me, I'm using the AMDGPU drivers with powerplay enabled, using a custom linux4.5 kernel. AMD r9 380 video card.
| What | Removed | Added |
|---|---|---|
| CC | matias.locatti@gmail.com |
*** Bug 95308 has been marked as a dupl= icate of this bug. ***
| What | Removed | Added |
|---|---|---|
| Status | NEW | NEEDINFO |
Any chance VALVe introduced this? They won't admit it. ht= tps://github.com/ValveSoftware/steam-for-linux/issues/4409 The patches attatched here are present in Linux 4.6. I tested linux-git-4.7= -rc7 with mesa-git-12.1 compiled against llvm-snv-3.9, and TF2 still crashes. Setting every graphical option to Low doesn't help.
This is certainly a bug in our driver (unlike what was written= on the Github tracker, a game *can* cause a hang e.g. by writing an infinite loop in a shader, but that seems exceedingly unlikely in the case of TF2). The problem with this particular bug is that it seems non-deterministic (i.e. not relia= bly reproducible), and that makes it hard to debug.
So there's a chance it won't be fixed at all? I was thinking about bisecting from version 3.16 (where I know it worked for me, on Debian Jessie) until ~4.1, but I don't have that kind of time right = now.
Actually, if you could find a clear bisection result, that wou= ld be tremendously helpful and would probably lead to a fix. However, with this kind of bug you need to be extremely sure about what you= 're doing when bisecting. For example, if you know that the hang typically occu= rs after 10 minutes, then you should play for at least one hour (perhaps even longer) with each kernel. Otherwise, you might have just gotten lucky, and = the bisect result would be worse than useless.
Yes, I would definitely test it for a long period, something l= ike 16 hours hehehe. However, I can't do any besecting right now, I'm tremendously busy at the moment. Too bad there's not many Linux players with this problem, otherwise someone would have figured this out already. Cheers.
Does this fix it? https://cgit.freedesktop.org/mesa/mesa/commit= /?id=3D947e0614d091c260651e4f3d6209bd6bcc2cfa0d In other words, does mesa/master work?
| What | Removed | Added |
|---|---|---|
| Status | NEEDINFO | REOPENED |
I can confirm lastest git head (50b49d242d702e4728329cc59f87d9= 29963e7c53) still causes lockups, though they seem to come much faster. Also seems to have a regression regarding lighting, I'll see about bisecting that in a separate report. LLVM: 3.8.0 DRM: 2.43.0 Linux: 4.6.3-gentoo