| Bug ID | 97137 |
|---|---|
| Summary | R7 M370 hangs with radeon.dpm=3D1 when running demanding grap= hical programs with DRI PRIME |
| Product | DRI |
| Version | DRI git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/Radeon |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | registo.mailling@gmail.com |
I own a laptop (Thinkpad E560) with an Intel+Radeon gpu combo.= When trying to run demanding graphical programs with the radeon gpu via dri prime it hangs= . In this context, demanding programs are anything more demanding than glxgears (which runs fine). If I boot with radeon.dpm=3D0 everything runs fine but at the low default c= lock speeds. I have been unable to set faster clock speeds via the sysfs interfa= ce. I have tried drm-next from https= ://cgit.freedesktop.org/~airlied/linux/?h=3Ddrm-next together with the latest git linux-firmware but the problem is the same. The problem can be replicated by running 'glmark2 -b texture'. However 'glm= ark2 -b build' seems to work without any problems.
Created attachment 125426 [details]
dmesg with gpu hang
Does setting radeon.runpm=3D0 on the kernel command line in gr= ub help?
(In reply to Alex Deucher from comment #3) > Does setting radeon.runpm=3D0 on the kernel comm= and line in grub help? No change. When running glmark2 I still get a hang when it gets to the text= ure test. I see the cube spin for maybe less than one second and then the test/= gpu hangs.
Created attachment 1=
25429 [details]
dmesg with radeon.runpm=3D0
| What | Removed | Added |
|---|---|---|
| CC | registo.mailling@gmail.com |
Is there any further information or tests I can do to help det= ermining the cause of the problem and finding a fix/workaround?
I have just noticed that the hang does not happen if I run 'gl= mark2 -b texture' while on battery, however the fps result is a lot lower than with the Intel gpu.=20 Might this provide any further clues to the problem?
| What | Removed | Added |
|---|---|---|
| Resolution | --- | FIXED |
| Status | NEW | RESOLVED |
This is now working for me. The fix was introduced sometime between stable kernel 4.8.6 and 4.8.7 and is still working fine with 4.8.11. I haven't tried to find exactly which commit fixed things but given that it= 's working now I'll let it rest. If later there is a regression I now have a g= ood starting point for a bisect and new bug report.