[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 #12 from jackdachef at gmail.com ---
(In reply to comment #11)
> I had to restart due to some other issue
> 
> and it wouldn't "successfully" resume anymore:
> 
> the lag/slowdown was there again
> 
> 
> forcing performance_level to "low" or "auto" didn't seem to make a difference
> 
> 
> so I'll try a 3.11-rc2* kernel in the weekend then - provided of course that
> it runs without other problems
> 
> 
> could it be related to reboot from Windows (windows 8 -> linux) that resume
> worked properly ?

had the chance to test it on latest 3.11-rc2-something kernel with most recent
drm-fixes

and exactly the same:

after resume (from X - suspended from the Xfce menu at the right corner) the
composited desktop is really really slow + the following behavior (I try to
make the description of the "slowness" as clear as possible so you can draw
conclusions easily) 

and after some time of slow browsing via chromium, dmesg-output without
crashing, etc. - surfing over and attempting to type in some data into this bug
entry - X crashed and xdm/lightdm attempted several times to reload until
screen stayed black with only one cursor point blinking at the left upper
corner - attempted to switch to VT1, VT2, etc. didn't work, magic sysrq + r and
then attempt to switching to VT (which had worked with patched up 3.10 kernel)
for a short moment showed the logon line on VT1 and then screen stayed black,
tried that several times - then it stayed completely black only with the cursor
at the left upper corner blinking

Jul 27 22:43:57 localhost kernel: [ 1380.040292] radeon 0000:01:00.0: GPU
lockup CP stall for more than 10000msec
Jul 27 22:43:57 localhost kernel: [ 1380.040300] radeon 0000:01:00.0: GPU
lockup (waiting for 0x0000000000000431 last fence id 0x0000000000000430)
Jul 27 22:44:06 localhost kernel: [ 1388.818320] SysRq : Keyboard mode set to
system default
Jul 27 22:44:09 localhost kernel: [ 1391.668196] SysRq : Keyboard mode set to
system default
Jul 27 22:44:25 localhost kernel: [ 1407.683331] SysRq : Keyboard mode set to
system default
Jul 27 22:44:28 localhost kernel: [ 1410.906535] SysRq : Keyboard mode set to
system default
Jul 27 22:44:29 localhost kernel: [ 1411.308996] SysRq : Terminate All Tasks

after that rebooted via magic sysrq + reisub


"slowness":

*) my default 2 gnome-terminal windows (the left one attached to the left side
of the monitor output), so that at the right side there's room for almost a
third window (http://img845.imageshack.us/img845/8577/kfe8.jpg)

*) when left-clicking on the middle of the left gnome-terminal and then moving
the window slowly (keeping left button pressed) the window slowly (with
stuttering) is shown on the movement, where it normally is shown during the
whole movement at every position - so it rather resembles a slide-show than
smooth movement with approx. 0.5 cm distance between the corners of the window
on a 22" screen

*) when attempting to fast moving the window (accelerated mouse movement) the
cursor - like in a loop - is moving diagonally from the upper left corner of
the window across the right lower corner of the window (a little bit further) -
seems like the driver (is it even the driver ?) has issues working with the
screen resolution



also: video acceleration of the pepperflash flash in chromium/google-chrome
doesn't seem to work properly with the new DPM driver - every video seems to
stutter (either "low" or "auto")

with the old driver even at "low" profile it appeared smooth


latest attempts on 3.10-patched kernel and 3.11-rc2* were compiled with gcc
4.7.2

-- 
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/20130727/1230c9d2/attachment.html>