|Summary:||Radeon, KMS, 6.12.99: Sleeping screen doesn't wake up reliably|
|Product:||DRI||Reporter:||Oliver Winker <oliverml1>|
|Component:||DRM/Radeon||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED MOVED||QA Contact:|
|Priority:||medium||CC:||niels_ole, oliverml1, razamatan, tomi.orava|
|i915 platform:||i915 features:|
Description Oliver Winker 2010-03-18 13:09:50 UTC
Created attachment 34216 [details] [review] Xorg.0.log Hi, Using the Radeon 6.12.99 driver with KMS (kernel 2.6.33), my screen sometimes remains sleeping, even if the display is actually woken up. I need to turn off/on the screen then to get something visible again. It's not happening regularly however. I would say in 60% of the cases, the screen wakes up Ok from sleep - in the others: turn off/on. The xorg log is attached; should contain all relevant info. If more is required, just tell. Apart from that the Radeon driver with KMS works quite well :)! Cheers, Oliver
Comment 1 Oliver Winker 2010-03-20 01:30:47 UTC
Hello, Some additional findings: * http://bugs.freedesktop.org/show_bug.cgi?id=26408 reports a similar problem; maybe they are linked ? A difference with a laptop screen is, that on my desktop I can turn off/on the screen to reset. The reporter of #26408 states, that the problem exists already since longer. That I can't exclude, since I only use the HD4850 only since recently. Before I was using a 8800GT ... which then broke it's video ram (and I didn't feel like trying the baking trick ;). With the 8800GT and the Nvidia driver the screen always woke up from whatever state. * In the meanwhile I'm trying the radeon_drv 6.12.192 - maybe that makes a difference. Cheer, Ol
Comment 2 Oliver Winker 2010-03-20 07:13:00 UTC
Problem remains also with radeon_drv 6.12.192 . -Ol
Comment 3 Alex Deucher 2010-10-19 19:23:46 UTC
Is this still an issue with a newer version of the kernel or driver?
Comment 4 Oliver Winker 2010-10-20 12:40:54 UTC
(In reply to comment #3) > Is this still an issue with a newer version of the kernel or driver? I recently thought to myself, that indeed, it somehow became better (now kernel 220.127.116.11, Xorg 1.7.7, radeon 6.13.1) ... . However it's not 100% reliable yet. My impression is, that specifically when the screen sleeps for a longer time (~>30min), then the wake-up doesn't always work. Difficult to quantify, since it's sporadic. I should start a systematic statistical observation, to get something more objective ;).
Comment 5 razamatan 2011-01-09 21:26:29 UTC
i have an rs690 (onboard desktop mobo), 2.6.36-r5, xorg 1.9.2, mesa 7.9, and xf86-video-ati 6.13.2. i'm having similar issues when getting out of sleep. the display appears to be hung, and i have to switch to a console and back. usually, i have to wait awhile and the screen comes back. i'll have to try turning off my monitor off/on forcefully to see if that helps my monitor come back. sometimes it takes a minute if i just let it go. i also suffer from the display randomly blanking for 1-3 seconds when the box is busy. it always comes back fine though... nonetheless really annoying. it's really bad if i don't set drm_kms_helper.poll = 0. i'm thinking there's something screwy going on with polling getting out of sleep.
Comment 6 Alex Deucher 2011-01-10 08:46:35 UTC
(In reply to comment #5) > i also suffer from the display randomly blanking for 1-3 seconds when the box > is busy. it always comes back fine though... nonetheless really annoying. As I mentioned on IRC, this issue is may be related to bug 32556. Please try the patches/suggestions there. Also, what size screen(s) do you have attached. The blanking during busy sounds like display fifo underflow.
Comment 7 razamatan 2011-01-19 12:12:15 UTC
(In reply to comment #6) > As I mentioned on IRC, this issue is may be related to bug 32556. Please try > the patches/suggestions there. Also, what size screen(s) do you have attached. > The blanking during busy sounds like display fifo underflow. i took a look at the following patches: https://bugs.freedesktop.org/attachment.cgi?id=41852 https://bugs.freedesktop.org/attachment.cgi?id=41376 and assumed that these were the ones to try. however, they don't apply cleaning on my 2.6.36 kernel (specifically, gentoo-sources-2.6.36-r5 from gentoo distribution)
Comment 8 Oliver Winker 2011-01-22 01:25:58 UTC
I just wanted to add, that the problem why I filed the bug report looks, for me at least, more related to sleeping/powersaving of the _screen_ (the display) itself. It's an Asus VW222U. The screen, after inactivity of some minutes, goes in standby/sleep and when I then try to wake it up, e.g. by moving the mouse, it is not reliably turning back on again. Then I need to manually, using the power button, turn the screen off and back on - everything else is ok. And this used to work before, with an nvidia card and the same screen (and also works now e.g. under a windows driver). So it doesn't look to me like a fifo-underflow (it's not winking at me, as Jesse Barnes would say ;). I still observe this with: - Kernel 2.6.37 - xserver-xorg 1:7.5+8 - xserver-xorg-core 2:1.7.7-10 - xserver-xorg-video-radeon 1:6.13.1-2+squeeze1 G+, Oliver
Comment 9 Alex Deucher 2011-01-22 09:59:17 UTC
(In reply to comment #8) > The screen, after inactivity of some minutes, goes in standby/sleep and when I > then try to wake it up, e.g. by moving the mouse, it is not reliably turning > back on again. Then I need to manually, using the power button, turn the screen > off and back on - everything else is ok. And this used to work before, with an > nvidia card and the same screen (and also works now e.g. under a windows > driver). Yeah, this is getting off track. Do the patches on this bug help your issue (wake up reliability)? https://bugzilla.kernel.org/show_bug.cgi?id=26552
Comment 10 Oliver Winker 2011-01-27 10:19:45 UTC
Hi, since yesterday I tried the 'combined patch' (pll_fix.diff) of bug 26552, and it's indeed looking better ;). Since it was always a bit sporadic, I'll continue monitoring the coming days and also with other Standby/Suspend settings (via the KDE power management). Will still give an update then. G+ and Thanks already! Oliver
Comment 11 Oliver Winker 2011-01-29 09:52:28 UTC
So, mixed news: After some longer day-to-day use today, what I observe is, that it got quite a bit better, however it still happens regularly, that the screen is not waking up. So overall the wakeup-reliability became better, but it's not yet 100%. Let me know, if there are things that I can assist with for debugging, testing, etc. -Oliver
Comment 12 razamatan 2011-02-19 02:20:34 UTC
i got fed up and tried switching monitors. as a result my issues went away. i was using a dell 2209wa which had the issues described in comment 7 (https://bugs.freedesktop.org/show_bug.cgi?id=27184#c7). i'm now using a samsung syncmaster 226bw with no issues. i would love to figure out what was going on though. i still have the dell monitor. i'm somewhat inclined to try and use a different dvi cable since the thickness difference between the cables for the monitors are quite noticeable.
Comment 13 tomi.orava 2011-11-12 13:12:05 UTC
I have this very same problem, after the power management puts the lcd-monitor to sleep, the physical monitor won't wake up anymore without doing a power off/power on for the lcd-screen. I used the ati catalyst drivers for quite some time and the display suspend worked just fine ---> whenever the computer display gets reactivated, also the physical monitor screen gets activated. To me it looks like the open source radeon driver somehow incorrectly tries to wake up the monitor without succeeding after previous display suspending. I saw the same problem a year ago, but then the xf86-video-ati -driver wasn't anyway ready in supporting this particular video card. The problem happens every single time when the display gets suspended. - xorg-server 2:1.9.0-0ubuntu7.6 - xf86-video-ati 6.14.3 - - Benq G2400W lcd monitor - 05:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450]
Comment 14 tomi.orava 2011-11-12 13:14:35 UTC
Created attachment 53467 [details] [review] Xorg log of the system that fails to activate the physical monitor after display suspend
Comment 15 Alex Deucher 2011-11-12 13:23:03 UTC
What kernel are you using? Does a newer kernel help? Try 3.0 or 3.1.
Comment 16 Oliver Winker 2011-11-13 02:54:20 UTC
As a workaround in the meanwhile, I deactivated the KDE screen power-mgmt and just use an initial "xset dpms 240 0 0", which just triggers a "stand-by" after 240sec and no "suspend". This works without problems (stand-by and wakeup from). Anyway, I will also retry a bit and do some testing using "suspend" on a 3.1, to see if something changed.
Comment 17 Alex Deucher 2011-11-13 12:02:36 UTC
(In reply to comment #16) > As a workaround in the meanwhile, I deactivated the KDE screen power-mgmt and > just use an initial "xset dpms 240 0 0", which just triggers a "stand-by" after > 240sec and no "suspend". This works without problems (stand-by and wakeup > from). DPMS standby, suspend, and off states are all treated the same from the driver's perspective. The driver really only deals with 2 DPMS states on and off. > > Anyway, I will also retry a bit and do some testing using "suspend" on a 3.1, > to see if something changed. When you say suspend, are you talking about the DPMS display state, or suspend and resume of the entire laptop? The two are very different.
Comment 18 Oliver Winker 2011-11-14 14:01:30 UTC
(In reply to comment #17) > DPMS standby, suspend, and off states are all treated the same from the > driver's perspective. The driver really only deals with 2 DPMS states on and > off. Ok, interesting to know. Now somehow the way using "xset dpms 240 0 0" (stand-by) quite surely made a difference for me at the time (<3.1) - but I can't prove and explain in detail. Now currently I'm using "xset dpms 0 240 0" (suspend) with 3.1 and until now it wakes up quite reliable. Which would be in inline with your info, that the driver operates on the same two states, as with stand-by. Maybe I'll also retest again the KDE power mgmt setting way, where I originally observed the wake-up problem. Maybe it's some screwed side effect in the end. > > > > Anyway, I will also retry a bit and do some testing using "suspend" on a 3.1, > > to see if something changed. > > When you say suspend, are you talking about the DPMS display state, or suspend > and resume of the entire laptop? The two are very different. No, no - I'm really talking about pure display suspend/resume, on a desktop with an Asus screen. Only the display is suspended and should nicely wakeup again, when I tick the mouse ;).
Comment 19 tomi.orava 2012-02-14 10:43:41 UTC
Sorry about the disappearence for a long time. I thought I had enabled the notifications for this bug. It seems that I still have this very same problem even with kernel.org 3.2.5 kernel. The previously mentioned workaround "xset dpms 0 240 0" that helped someone, did not work in my setup at all. In case the following debug info helps at all: get-edid | parse-edid get-edid: get-edid version 2.0.0 Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Function supported Call successful VBE version 300 VBE string at 0xc0204 "ATI ATOMBIOS" VBE/DDC service about to be called Report DDC capabilities Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0 Function supported Call successful Monitor and video card combination does not support DDC1 transfers Monitor and video card combination supports DDC2 transfers 0 seconds per 128 byte EDID block transfer Screen is not blanked during DDC transfer Reading next EDID block VBE/DDC service about to be called Read EDID Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 [/pub/linux/kernel] alderan#root>get-edid | parse-edid 2>&1 get-edid: get-edid version 2.0.0 Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Function supported Call successful VBE version 300 VBE string at 0xc0204 "ATI ATOMBIOS" VBE/DDC service about to be called Report DDC capabilities Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0 Function supported Call successful Monitor and video card combination does not support DDC1 transfers Monitor and video card combination supports DDC2 transfers 0 seconds per 128 byte EDID block transfer Screen is not blanked during DDC transfer Reading next EDID block VBE/DDC service about to be called Read EDID Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 parse-edid: parse-edid version 2.0.0 Function supported Call successful parse-edid: EDID checksum passed. # EDID version 1 revision 3 Section "Monitor" # Block type: 2:0 3:ff # Block type: 2:0 3:fd # Block type: 2:0 3:fc Identifier "BenQ G2400W" VendorName "BNQ" ModelName "BenQ G2400W" # Block type: 2:0 3:ff # Block type: 2:0 3:fd HorizSync 31-94 VertRefresh 50-85 # Max dot clock (video bandwidth) 170 MHz # Block type: 2:0 3:fc # DPMS capabilities: Active off:yes Suspend:no Standby:no Mode "1920x1200" # vfreq 59.950Hz, hfreq 74.038kHz DotClock 154.000000 HTimings 1920 1968 2000 2080 VTimings 1200 1203 1209 1235 Flags "-HSync" "+VSync" EndMode # Block type: 2:0 3:ff # Block type: 2:0 3:fd # Block type: 2:0 3:fc EndSection
Comment 20 Alex Deucher 2012-02-14 11:07:38 UTC
Does kernel 3.3rc3 or newer work any better?
Comment 21 Oliver Winker 2012-02-14 12:36:44 UTC
Hi, Just for info: in my case, since quite some time using 3.1 and 3.2 (and on debian xorg 7.6+11, radeon 6.14.3-2) the screen wake-up works quite reliable now, without the xset dpms workaround. I kept postponing to give an update on this on - sorry. Anyway, it looks better here in the meanwhile ;). BR, Oliver
Comment 22 tomi.orava 2012-02-14 22:49:18 UTC
(In reply to comment #20) > Does kernel 3.3rc3 or newer work any better? I tested with the latest git version from yesterday evening (13d261932bbfff7f45f288c5c8cce43177cccd3b) and unfortunately none of the "xset dpms force off, standby or suspend" worked any differently than before. The BenQ monitor just decides to stay in power saving mode and the only way to wake it up is to power cycle the monitor. There really is nothing wrong with the hardware as the fglrx is able to use dpms power management just fine.
Comment 23 tomi.orava 2012-02-26 23:29:12 UTC
I just updated to latest Ubuntu 12.04 pre-release and the combination ATI 5450 together with BenQ LCD monitor doesn't work any better than before. The system is still running with the kernel.org 3.3-rc3+ kernel from git. I wonder what kind of information would help in figuring out why this particular combination doesn't wake up from standby ? Below is some info & logs about the current configuration. 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cedar PRO [Radeon HD 5450] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 0366 Flags: bus master, fast devsel, latency 0, IRQ 47 Memory at e0000000 (64-bit, prefetchable) [size=256M] Memory at fdec0000 (64-bit, non-prefetchable) [size=128K] I/O ports at ac00 [size=256] Expansion ROM at fdea0000 [disabled] [size=128K] Capabilities:  Power Management version 3 Capabilities:  Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities:  Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities:  Advanced Error Reporting Kernel driver in use: radeon Kernel modules: radeon - xorg-server 2:1.11.4-0ubuntu4 [ 105.589] (II) Module radeon: vendor="X.Org Foundation" [ 105.589] compiled for 1.11.3, module version = 6.14.99 [ 105.589] Module class: X.Org Video Driver [ 105.589] ABI class: X.Org Video Driver, version 11.0
Comment 24 tomi.orava 2012-02-26 23:31:00 UTC
Created attachment 57700 [details] [review] Updated Xorg.log from pre-release Ubuntu 12.04 setup
Comment 25 tomi.orava 2012-04-04 04:39:41 UTC
I just happened to test with this very same 3.3.0-rc3 kernel that while I was in linux console ie. no X and the screen blanker got activated, the lcd display was put into suspend mode ---> I hit the keyboard at this stage and the screen came back without fuss. Last time when I tried all the different stages with xset, none of them worked well. Is there an easy way to modify the states the console screen saver is using (for testing purposes) ?
Comment 26 Alex Deucher 2012-04-04 06:07:48 UTC
(In reply to comment #25) > I just happened to test with this very same 3.3.0-rc3 kernel that while I was > in linux console ie. no X and the screen blanker got activated, the lcd display > was put into suspend mode ---> I hit the keyboard at this stage and the screen > came back without fuss. Last time when I tried all the different stages with > xset, none of them worked well. Is there an easy way to modify the states the > console screen saver is using (for testing purposes) ? You can use xset to test dpms, e.g., xset dpms force off Also, for what it's worth, the driver only implements two states: on and off. All of the intermediate dpms states that are not "on" map to "off".
Comment 27 tomi.orava 2012-05-11 13:14:35 UTC
> You can use xset to test dpms, e.g., > xset dpms force off > > Also, for what it's worth, the driver only implements two states: on and off. > All of the intermediate dpms states that are not "on" map to "off". What I meant was the problem existed also in linux console, outside of X11. However, it seems that at least the LCD display seems to work just fine with an old ATI HD 2400 card & radeon driver (dpms works just fine): 08:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV610 video device [Radeon HD 2400 PRO] I'll try the latest git version of kernel.org kernel as there has been some updates to DVI connectors/connections code for radeon to my knowledge.
Comment 28 Justin Stressman 2013-11-24 18:39:49 UTC
I'm seeing the same kind of issue here on my 3 monitor setup with Dell u2412m monitors. The 2 DVI connected monitors wake every time, but the Display Port one rarely wakes if the screen has been off for awhile. I have so far been loading display properties and making a change to that monitor (like rotating it) and hitting apply, which wakes it, and then just reverting the changes. Powering off and back on again didn't seem to help if I recall correctly. I'll have to try again the next time I run into the issue. video card: [AMD/ATI] Tahiti XT [Radeon HD 7970/R9 280X] Software: - xorg-server 1.14.3 - mesa 9.2.1 - xf86-video-ati 7.2.0 - glamor 0.5.1 - libdrm 2.4.0 (?)
Comment 29 Justin Stressman 2013-11-24 18:41:38 UTC
Also, the kernel I'm running is the following version: Linux version 3.11.0-13-generic (buildd@roseapple) (gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8) ) #20-Ubuntu SMP Wed Oct 23 07:38:26 UTC 2013
Comment 30 Justin Stressman 2013-11-24 22:52:58 UTC
Just had it not come back on again, so I tested the power off/on trick to get it working again and it did work. :D That's a big help for now at least.
Comment 31 Martin Peres 2019-11-19 08:10:56 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/107.