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


 

Problem remains also with radeon_drv 6.12.192 . 

-Ol

Is this still an issue with a newer version of the kernel or driver?

(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 2.6.35.4, 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 ;).

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.

(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.

(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)

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

(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

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

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

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.

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]

Created attachment 53467 [details] [review]
Xorg log of the system that fails to activate the physical monitor after display suspend

What kernel are you using?  Does a newer kernel help?  Try 3.0 or 3.1.

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.

(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.

(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 ;).

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

Does kernel 3.3rc3 or newer work any better?

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

(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.

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: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [150] 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

Created attachment 57700 [details] [review]
Updated Xorg.log from pre-release Ubuntu 12.04 setup

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) ?

(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".

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

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 (?)

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

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.

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