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

* [Bug 67002] New: evergreen: after resume from suspend-to-ram operation is really slow with the latest DPM changes
@ 2013-07-17 15:10 bugzilla-daemon
  2013-07-17 15:10 ` [Bug 67002] evergreen: after resume from suspend-to-ram operation is really slow with the latest DPM changes + gpu lockup bugzilla-daemon
                   ` (14 more replies)
  0 siblings, 15 replies; 16+ messages in thread
From: bugzilla-daemon @ 2013-07-17 15:10 UTC (permalink / raw)
  To: dri-devel

[-- Attachment #1.1: Type: text/plain, Size: 7587 bytes --]

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

          Priority: medium
            Bug ID: 67002
          Assignee: dri-devel@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@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.

[-- Attachment #1.2: Type: text/html, Size: 9166 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread