All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 67002] New: evergreen: after resume from suspend-to-ram operation is really slow with the latest DPM changes
Date: Wed, 17 Jul 2013 15:10:28 +0000	[thread overview]
Message-ID: <bug-67002-502@http.bugs.freedesktop.org/> (raw)


[-- 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

             reply	other threads:[~2013-07-17 15:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17 15:10 bugzilla-daemon [this message]
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
2013-07-19 12:54 ` bugzilla-daemon
2013-07-19 15:35 ` bugzilla-daemon
2013-07-19 15:37 ` bugzilla-daemon
2013-07-19 16:51 ` bugzilla-daemon
2013-07-19 17:26 ` bugzilla-daemon
2013-07-19 17:44 ` bugzilla-daemon
2013-07-20 15:42 ` bugzilla-daemon
2013-07-24 10:07 ` bugzilla-daemon
2013-07-24 14:45 ` bugzilla-daemon
2013-07-24 20:05 ` bugzilla-daemon
2013-07-24 21:30 ` bugzilla-daemon
2013-07-27 21:24 ` bugzilla-daemon
2013-07-27 21:37 ` bugzilla-daemon
2019-11-19  8:36 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-67002-502@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.