| Bug ID | 92258 |
|---|---|
| Summary | Opening context menu in Steam could lead to radeon kernel module crash |
| Product | DRI |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | critical |
| Priority | medium |
| Component | DRM/Radeon |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | russianneuromancer@ya.ru |
Created attachment 118630 [details]
dmesg log
This crash (please look into attached dmesg) happen hot every time when I open
context menu in Steam, but could happen like two times per evening. Since I
notice this crash lately, this is probably related to some latest changes in
Linux 4.2, but I could be wrong here. On Linux 4.3 this crash is also
reproducible.
This issue seems like related to DRI_PRIME usage (at least I was unable to
easily reproduce this if Steam launched without DRI_PRIME) or maybe to
particular GPU model (integrated is 6620G, discrete 6650M).
DRI3 and GLAMOR is used, that also may be related.
Software:
Kubuntu 15.10 x86_64
Mesa: 11.0
libdrm-radeon1: 2.4.64
xserver-xorg-video-radeon: 7.5.0+git20150819
xserver-xorg-core: 1.17.2
Hardware:
Acer Aspire 7560G laptop,
AMD APU A8-3500M with integrated Radeon HD 6620G (SUMO)
Discrete AMD Radeon HD 6650M (TURKS)
Created attachment 118908 [details]
netconsole log
With Linux 4.3rc5 system became unresponsive after crash, there is even no
reaction when I press NumLock button (NumLock led doesn't change state) but
kernel continue to send backtraces via netconsole for some time. netconsole.log
is attached.
This crash happen only if Steam started on Radeon HD 6650M via DRI_PRIME.
This crash seems like could be triggered only by DRI3 and GLAMOR combination,
at least I was unable to easily reproduce it with DRI2&EXA and DRI3&EXA
combinations (DRI2&GLAMOR crash Xorg on Steam start, so I unable to test this
issue with this combination).
Quick update: I just able to reproduce this crash with DRI3&EXA combination. I also tried to update Mesa to latest build from Oibaf PPA, this doesn't help.
| What | Removed | Added |
|---|---|---|
| Summary | Opening context menu in Steam could lead to radeon kernel module crash | Opening context menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash |
After day of testing now I can say that this issue most likely starting with Linux 4.1.7. I was able to easily reproduce this crash with 4.1.7 but still can't reproduce with 4.1.6. (Tested with DRI3 and GLAMOR.)
| What | Removed | Added |
|---|---|---|
| Summary | Opening context menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash | [regression] Opening context menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash |
The crash looks like the TTM cleanup process tries to free a b= uffer twice. Most likely a bug in the reference counting somewhere. Can you try to bisect the DRM changes between 4.1.6 and 4.1.7? According to the git logs there wasn't even a single change radeon between 4.1.6 and 4.1.7 so this sounds like a problem in TTM.
Actually between 4.1.6 and 4.1.7 there are only four DRM patch= es, so that's rather unlikely to cause problems. No idea what's going wrong here.
Okay, after two days of uptime I able to reproduce this crash on 4.1.6 too, but for some reason 4.1.6 require different steps: this time I run Steam in Big Picture mode, then back to desktop mode, and then call not context menu, but click on Library button in Steam interface - Library menu appear, and then system lockup. Testing 4.1.5 now.
I have similiar problem on zbook 14 using open driver and DRI_PRIME=1 3.16.7 openSUSE 13.2 work without any problem Fedora 21 after update from 3.18 to 3.19 randomly crash using DRI_PRIME=1 4.1.12 openSUSE Leap 42.1 the same issue.
OpenSUSE Leap 42.1 default DRI2&GLAMOR
A foud something in Arch wiki, I But I do not know if it's the same problem.
Kernel crash/oops when using PRIME and switching windows/workspaces
Note: this has been tested on a system with Intel+AMD
Using DRI3 WITH a config file for the integrated card seems to fix this issue.
To enable DRI3, you need to recompile mesa with --enable-dri3 in the configure
flags[1] and create a config for the integrated card adding the DRI3 option:
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "DRI" "3"
EndSection
After this you can use DRI_PRIME=1 WITHOUT having to run xrandr
--setprovideroffloadsink radeon Intel as DRI3 will take care of the offloading.
https://wiki.archlinux.org/index.php/PRIME
| What | Removed | Added |
|---|---|---|
| CC | bugs@mblankhorst.nl |
Looks like something goes wrong in ttm_bo_wait. Maarten, any i= deas offhand what could go wrong there, or how to narrow it down?
Created attachment 119927 [details] [review] Use reservation_object_wait_timeout_rcu I have no idea what can go wrong, lets find out if adding refcounts during wait helps.. Could you check the output with this patch? ^
If this causes a GPF in ttm_bo_wait my guess is radeon has a fence refcounting bug, but if that's the case this patch will cause an infinite loop in reservation_object_wait_timeout_rcu called from ttm_bo_wait.
how to use this patch? I reported this bug on opensuse bugzilla, there's more info https://bugzilla.opensuse.org/show_bug.cgi?id=954783
Michel, Maarten, seems like issue that I reported originally is not same issue
that polo reporting. For me DRI3 usage cause kernel module crash, for him using
DRI3 instead of DRI2 is kind of workaround.
What you think?
> Could you check the output with this patch?
Honestly, I doesn't know how to test it, as I am not developer. But I can test
rc-kernels that available in Ubuntu mainline PPA.
| What | Removed | Added |
|---|---|---|
| CC | deathsimple@vodafone.de |
(In reply to russianneuromancer from comment #13) > Michel, Maarten, seems like issue that I reporte= d originally is not same > issue that polo reporting. For me DRI3 usage cause kernel module crash= , for > him using DRI3 instead of DRI2 is kind of workaround.=20 > What you think? It's probably better if polo files his/her own upstream report then, or sti= cks to the downstream one. Since that problem seems to be a regression, it shou= ld be possible to isolate it with git bisect. (In reply to Maarten Lankhorst from comment #11) > If this causes a GPF in ttm_bo_wait my guess is = radeon has a fence > refcounting bug, [...] Indeed, that happened in https://bugs.freedesktop.org/show_bu= g.cgi?id=3D93017#c5 . Christian, any ideas where our fence reference counting might be wrong?
| What | Removed | Added |
|---|---|---|
| Summary | [regression] Opening context menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash | [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash |
Title changed per comment #6 Still reproducible, on Linux 4.4 too.
| What | Removed | Added |
|---|---|---|
| See Also | https://bugs.freedesktop.org/show_bug.cgi?id=94667 |
Also affects me. Intel HD3000 + AMD Radeon HD 6550m. Easy way to reproduce. Launch anygame in wine with DRI_PRIME=1 I tried WoW and NFS:Underground. Freeze happen in 2-3 seconds in NFS and 10-15 minutes in WoW Kdump - no record. Netconsole - empty output.
(In reply to Maarten Lankhorst from comment #10) > Created attachment 119927 [details] [review] [review] > Use reservation_object_wait_timeout_rcu > > I have no idea what can go wrong, lets find out if adding refcounts during > wait helps.. > > Could you check the output with this patch? ^ Checked a 4.5.0 kernel with this patch. No changes. Suffering kernel freezes. I built package and sent to OP to help him make some logs of this.