[Bug 67002] New: evergreen: after resume from suspend-to-ram operation is really slow with the latest DPM changes
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Wed Jul 17 08:10:28 PDT 2013
https://bugs.freedesktop.org/show_bug.cgi?id=67002
Priority: medium
Bug ID: 67002
Assignee: dri-devel at lists.freedesktop.org
Summary: evergreen: after resume from suspend-to-ram operation
is really slow with the latest DPM changes
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: jackdachef at gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: XOrg CVS
Component: DRM/Radeon
Product: DRI
Using the drm-code from drm-fixes-3.11 branch
(http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11) against a 3.10
final kernel as explained in following post
(http://phoronix.com/forums/showthread.php?82357-drm-fixes-3-11-with-3-10-stable-kernel-patch-repo)
the card used is a HD5850, evergreen; ~amd64 Gentoo Linux, Intel Core i7 860,
gcc 4.8.1, 2.17
I tested suspend-to-ram which in a prior state of drm-next would lock up the
box (so much progress has been made - yay ! :) ):
via following command:
pm-suspend --quirk-dpms-on --quirk-s3-mode --quirk-vbe-post --quirk-vga-mode3
launched from VT1 (no X running)
first things noticable:
it takes longer (compared to the non-DPM driver) to turn off the computer so I
first thought that it had hardlocked (fans were still spinning, screen turned
off, harddisks +/- off - after some time the box went to suspend/sleep)
it also takes longer to resume and for the screen to turn on
following behavior is observable after the resume from suspend-to-ram:
dmesg shows:
[ 178.031724] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[ 178.430546] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control:
Rx
[ 178.430652] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO
[ 179.052821] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[ 180.073918] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[ 181.095014] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[ 182.116110] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[ 182.120733] ata1: link is slow to respond, please be patient (ready=0)
[ 182.122735] ata3: link is slow to respond, please be patient (ready=0)
[ 182.128740] ata5: link is slow to respond, please be patient (ready=0)
[ 182.130763] ata6: link is slow to respond, please be patient (ready=0)
[ 183.137207] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[ 184.158303] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[ 185.179399] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[ 186.200496] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[ 186.817477] ata1: COMRESET failed (errno=-16)
[ 186.819524] ata3: COMRESET failed (errno=-16)
[ 186.825487] ata5: COMRESET failed (errno=-16)
[ 186.827492] ata6: COMRESET failed (errno=-16)
[ 187.221593] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[ 187.241615] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
[ 187.241618] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD
(-1).
[ 187.241650] [drm] ib test on ring 0 succeeded in 0 usecs
[ 187.241683] [drm] ib test on ring 3 succeeded in 1 usecs
[ 187.246731] switching from power state:
[ 187.246732] ui class: none
[ 187.246733] internal class: boot
[ 187.246733] caps: video
[ 187.246734] uvd vclk: 0 dclk: 0
[ 187.246734] power level 0 sclk: 40000 mclk: 90000 vddc: 1000
vddci: 0
[ 187.246735] power level 1 sclk: 40000 mclk: 90000 vddc: 1000
vddci: 0
[ 187.246735] power level 2 sclk: 40000 mclk: 90000 vddc: 1000
vddci: 0
[ 187.246736] status: c b
[ 187.246736] switching to power state:
[ 187.246737] ui class: performance
[ 187.246737] internal class: none
[ 187.246738] caps: single_disp video
[ 187.246738] uvd vclk: 0 dclk: 0
[ 187.246739] power level 0 sclk: 15700 mclk: 30000 vddc: 950
vddci: 1100
[ 187.246739] power level 1 sclk: 55000 mclk: 90000 vddc: 1038
vddci: 1100
[ 187.246740] power level 2 sclk: 72500 mclk: 100000 vddc: 1088
vddci: 1100
[ 187.246740] status: r
[ 188.350006] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 188.380064] ata3.00: configured for UDMA/133
[ 188.380117] sd 2:0:0:0: [sdb] Starting disk
[ 188.511188] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 188.523242] ata6.00: configured for UDMA/133
[ 188.523276] sd 5:0:0:0: [sdd] Starting disk
[ 190.500189] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 190.513376] ata5.00: configured for UDMA/133
[ 190.513455] sd 4:0:0:0: [sdc] Starting disk
[ 191.462213] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 191.506493] ata1.00: configured for UDMA/133
[ 191.506573] sd 0:0:0:0: [sda] Starting disk
[ 192.356977] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than
5secs aborting
[ 192.356978] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing
D3DE (len 55, WS 0, PS 0) @ 0xD401
[ 192.376632] PM: resume of devices complete after 15600.251 msecs
so suspend & resume works but with caveats - now wanted to see how X is
running:
launched up lightdm & logged into xfce4.10 :
compiz-fusion (0.8*)/compositing is very very slow: e.g. when grabbing a window
at the top with left mouse button and trying to move it - it moves only for
several millimeters on screen (22'' screen with 1920x1080 resolution) - thus
unusable
when switching to xfwm4 (running Xfce4.10) moving windows around is somewhat
acceptable - appears even fluid, launching up chromium and switching between
tabs via ctrl + pgup/pgdown is noticably laggy
launching glxgears via gnome-terminal - it seemingly looks ok (gears smoothly
turning) [FPS locked to around 60]
running glxgears via: R600_LLVM=0 vblank_mode=0 glxgears
there's noticable, "micro"-stuttering and the FPS is around 260-290 if I recall
correctly
echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level
or
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
doesn't make a difference - also FPS is significantly lower compared to
"normal" operation (around 10x faster, e.g. 2900-3600 FPS with the non-DPM and
"high" profile)
next step was launching gnome-terminal from the below panel, then after sudo su
-> dmesg
and wanted to do further tests (e.g. sensors output)
-> X crashed
[ 973.217246] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec
[ 973.217254] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000000199
last fence id 0x0000000000000198)
X (or lightdm) couldn't be launched after that anymore, VT output was still
shown - so I restarted via shutdown -r now
hope that information helps in tracking down this issue
I really love this new driver - now only operation after resume needs to work
also, since I used it quite a lot :) (it does work with the non-DPM)
similar message and behavior was seen on july 3rd/4th after several hours of
operation & uptime (no suspend and resume):
[ 973.217246] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec
[ 973.217254] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000000199
last fence id 0x0000000000000198)
--
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/20130717/b27342e4/attachment-0001.html>
More information about the dri-devel
mailing list