Bug 76761
| Summary: | radeon DPM breaks suspend to disk and resume from RAM in 3.14 | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Vitaliy Filippov (vitalif) |
| Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
| Status: | NEW --- | ||
| Severity: | high | CC: | alexdeucher, bjoernv, hafflys, swoorupj, szg00000 |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.14.4 (debian 3.14.4-1 amd64) | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
possible fix
better fix |
||
|
Description
Vitaliy Filippov
2014-05-22 19:35:12 UTC
Can you bisect? Yes, I can try to bisect... Just found Bug 63391 (Radeon RS880 doesn't resume from suspend with radeon dpm enabled), and also tried to disable DPM - suspend works fine without it. But DPM is an important feature for me, without it the laptop easily gets VERY HOT! So I can't just disable DPM as it was done in Bug 63391... OK I did bisect. The result is: 6c7bccea390853bdec5b76fe31fc50f3b36f75d5 is the first bad commit commit 6c7bccea390853bdec5b76fe31fc50f3b36f75d5 Author: Alex Deucher <alexander.deucher@amd.com> Date: Wed Dec 18 14:07:14 2013 -0500 drm/radeon/pm: move pm handling into the asic specific code We need more control over the ordering of dpm init with respect to the rest of the asic. Specifically, the SMC has to be initialized before the rlc and cg/pg. The pm code currently initializes late in the driver, but we need it to happen much earlier so move pm handling into the asic specific callbacks. This makes dpm more reliable and makes clockgating work properly on CIK parts and should help on SI parts as well. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Do you need any other details about this bug? :) Alex, do you have any suggestions?.. It was a long weekend in the US. I haven't had a chance to look into it yet. Created attachment 137731 [details]
possible fix
Does this patch help?
Created attachment 137741 [details]
better fix
Please try this patch instead.
Yes, everything works with it, thanks! So, in which kernel version are you planning to include this fix? 3.15 is we can make it in in time, otherwise 3.16. I've cc'ed stable so it will show up in older kernels as well too once it's applied upstream. Thanks, I'll wait for the inclusion :-) Hi Alex, I have reported the same issue in bugs.freedesktop. I tried out the 3.15 linux kernel in archlinux just today. And this issue is still prevalent to me. Resuming from suspend still results a blank screen using the radeon module in the kernel. dmesg logs: http://ix.io/cSi I have a AMD A6-4400M APU that integrates Radeon HD 7520G. Kind Regards, Swoorup Joshi (In reply to swoorupj from comment #12) > Hi Alex, > > I have reported the same issue in bugs.freedesktop. I tried out the 3.15 > linux kernel in archlinux just today. And this issue is still prevalent to > me. Is it the same commit (6c7bccea390853bdec5b76fe31fc50f3b36f75d5) that caused the regression for you as well? If not, you are experienceing a different issue. (In reply to Alex Deucher from comment #13) > (In reply to swoorupj from comment #12) > > Hi Alex, > > > > I have reported the same issue in bugs.freedesktop. I tried out the 3.15 > > linux kernel in archlinux just today. And this issue is still prevalent to > > me. > > Is it the same commit (6c7bccea390853bdec5b76fe31fc50f3b36f75d5) that caused > the regression for you as well? If not, you are experienceing a different > issue. No, this issue has been occurring since kernel 3.8. Is there a way or patch, I could get all the state of the card and test how they differ before and after suspending? Since you know everything was ok in 3.8, maybe you'll just also try to bisect? :) Sorry I have mislead you. I meant I started using linux since 3.8. And I have had this problem since. I don't recall it working with KMS. swoorupj you have some other issue then. It's not related to this bug. Fedora kernel 3.15.x versions on an Acer Aspire One netbook with AMD C50 processor and Radeon driver has this problem. Kernel 3.14.x and earlier kernel versions did not have this problem. Whatever changed between 3.14.x and 3.15.x has caused this problem. I have a bug report at https://bugzilla.redhat.com/show_bug.cgi?id=1121838 but I think the problem will need to be addressed here, upstream from Fedora. Kernels 3.14 and under = work fine. Kernels 3.15.x != work I asked in the buzilla report cited above what changed that could cause this and how do I fix it? With Fedora working to rebase Fedora 20 to 3.16.x, if the problem has not been fixed, then there will be problems. This will be even more so when Fedora 21 is released and Fedora 19 becomes an E.O.L. version. I am currently running Fedora 20, but I have to use a Fedora 19 kernel (3.14.17-100.fc19.x86_64) in order to have suspend/resume work properly. Please don't ask me to bisect unless you give me explicit directions on how to do so. I have no idea what bisecting does or how to do it. I'm not a developer. |