[Bug 67002] evergreen: after resume from suspend-to-ram operation is really slow with the latest DPM changes + gpu lockup

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67002

--- Comment #10 from jackdachef at gmail.com ---
(In reply to comment #9)
> Maybe unrelated to this bug report, but with today's Linus' master
> (04012e3076943f17c8cfc77a196701c8f0b8964f) the only suspend/resume issue
> left is that I get:
> 
> [drm:rv770_stop_dpm] *ERROR* Could not force DPM to low.
> 
> in dmesg upon resume.
> 
> That is before the 'ring' and 'uvd' messages. It seems harmless, I didn't
> notice any problems. It can switch power levels later on, play videos via
> uvd... it just seems to try to do something with dpm too early in the resume
> process.

indeed - the recent changes made a difference

I'm currently posting from the kernel running from resumed suspend-to-ram

the only changes were

that I set to "auto"

 echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level

and am running that new kernel posted over at phoronix forums


probably will try out with forced "low" profile/performance_level in the
weekend and see if I get a similar message to yours

now I need the box up and running for work

will continue using it and see whether something strange occurs

if that's the case I'll post it here

otherwise it's running fine so far ...


Thanks a lot to everyone for the fixes & work ! 


on a side-note: the hardlocks I experienced in the past might have been due to
BFQ & some exotic setup/tweaks/additional patches that I'm using

so perhaps no hardlocks with the DPM code so far :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130724/c6591cd0/attachment.html>