| Bug ID | 90873 |
|---|---|
| Summary | GPU hang, TearFree On, Mate desktop environment |
| Product | Mesa |
| Version | git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | neatnoise@gmail.com |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 116320 [details]
dmesg
Hello,
I experience GPU hang while TearFree option is on. Logs are in the attachments.
Without TearFree option is okay. I've tested TearFree when this feature was
introduced in git version of xf86-video-ati-git and I didn't experience GPU
hang back then.
GPU: Radeon 7790
OS: Arch Linux, latest RC version kernel
mesa-git, llvm-svn, xf86-video-ati-git
Desktop environment: Mate 1.8
Best regards
(In reply to Tom from c= omment #0) > I experience GPU hang while TearFree option is o= n. Does it hang when you do anything in particular? FWIW, this line in dmesg is probably related: [ 141.232226] radeon 0000:01:00.0: bo ffff8804236d3400 va 0x0000001000 conflict with (bo ffff88042a018800 0x0000001000 0x0000001563) but I'm not sure what would cause that. > I've tested TearFree when this feature was intro= duced in git version of > xf86-video-ati-git and I didn't experience GPU hang back then. Can you try isolating the xf86-video-ati commit introducing the hang with g= it bisect?
(In reply to Michel D=C3=A4nzer from comment #3) > (In reply to Tom from comment #0) > > I experience GPU hang while TearFree option is on. >=20 > Does it hang when you do anything in particular? >=20 > FWIW, this line in dmesg is probably related: >=20 > [ 141.232226] radeon 0000:01:00.0: bo ffff8804236d3400 va 0x0000001000 > conflict with (bo ffff88042a018800 0x0000001000 0x0000001563) >=20 > but I'm not sure what would cause that. >=20 >=20 > > I've tested TearFree when this feature was introduced in git vers= ion of > > xf86-video-ati-git and I didn't experience GPU hang back then. >=20 > Can you try isolating the xf86-video-ati commit introducing the hang w= ith > git bisect? I investigated it a bit. When I start lightdm it starts fine. I've created = new linux user without any desktop config and it desktop env started also ok. T= hen I've changed resolution using desktop environment tool and then problem appeared. The same happened when used xrandr.
| What | Removed | Added |
|---|---|---|
| CC | deathsimple@vodafone.de | |
| Component | Drivers/Gallium/radeonsi | DRM/Radeon |
| Version | git | unspecified |
| Product | Mesa | DRI |
| Summary | GPU hang, TearFree On, Mate desktop environment | Kernel hang, TearFree On, Mate desktop environment |
| QA Contact | dri-devel@lists.freedesktop.org |
http://lists.freedesktop.org/archives/dri-devel/2015-Ju= ne/084514.html fixes the hang for me (not a GPU hang but a kernel hang, because it tries to lock a m= utex that's already locked). > [ 141.232226] radeon 0000:01:00.0: bo ffff88042= 36d3400 va 0x0000001000 > conflict with (bo ffff88042a018800 0x0000001000 0x0000001563) These still happen, but at least with GNOME it continues working for me somehow. I tried various workarounds for this in the Xorg driver, but I hav= en't found anything that avoids these. I think the proper solution for these wou= ld be for the kernel driver to track GPU VA ranges per GEM handle instead of p= er BO.
(In reply to Michel D=C3=A4nzer from comment #5) > http://lists.freedesktop.org/archives/dri= -devel/2015-June/084514.html fixes > the hang for me (not a GPU hang but a kernel hang, because it tries to= lock > a mutex that's already locked). >=20 >=20 > > [ 141.232226] radeon 0000:01:00.0: bo ffff8804236d3400 va 0x0000= 001000 > > conflict with (bo ffff88042a018800 0x0000001000 0x0000001563) >=20 > These still happen, but at least with GNOME it continues working for me > somehow. I tried various workarounds for this in the Xorg driver, but I > haven't found anything that avoids these. I think the proper solution = for > these would be for the kernel driver to track GPU VA ranges per GEM ha= ndle > instead of per BO. The latest patch applied to linux kernel rc8 fixed this issue, thanks.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |