Bug 38030

Does:
sleep 5; xset dpms force off
work?

Sometimes late input events come in which cause X to wake the display.

Nope. That makes no difference.

Checking more closely, doing a "sleep 5; xset dpms force off" just causes the monitor to go black, turn itself off a few seconds later and then turn back on again, returning to the original display. It's "sleep 5; xset dpms force suspend" that triggers the endless "turn on, turn off, turn on again" cycle, with the screen remaining black the entire time.

please attach your xorg log and dmesg output.  This might be an xserver issue as the radeon driver treats off and suspend the same.

Also what about a longer delay:

sleep 10; xset dpms force off/suspend

Make sure not to move the mouse or touch the keyboard after executing that line.

Created attachment 47677 [details]
dmesg output

Created attachment 47678 [details]
Xorg log

sleep 10 makes no difference.

I also see this behaviour when the gnome power management kicks in and turns
the screen off, so I don't think it's got anything to do with late arriving X
events.

NB. In case I'm not being clear: the screen doesn't come back displaying an
image: the monitor turns on with the display completely black, then it goes to
sleep again in a never ending cycle.

Playing with "sleep 10; xset dpms force off|suspend" it appears to be non-deterministic whether the screen comes back after one cycle, regardless of whether I choose off or suspend. I only ever see the continuous on/off cycling when the power management kicks in.

(Although of course I might not notice if the power management came back on after a single cycle, whereas I do notice when I come back to it and find it in it's  on/off cycling state because I forgot to turn it off by hand.)

I've only just noticed that the xserver is using the fbdev driver! How weird.

Sadly, forcing it to use the radeon driver (new Xorg attached) makes no difference to the suspend behaviour :(

(Turns out that without an xorg.conf, the xserver will only try xserver-xorg-video-ati, even if you have the radeon driver installed.)

Created attachment 47684 [details] [review]
Radeon Xorg log

Could this have anything to do with a daemon probing the monitor?

(In reply to comment #10)
> (Turns out that without an xorg.conf, the xserver will only try
> xserver-xorg-video-ati, even if you have the radeon driver installed.)

xf86-video-ati is the radeon driver.  It doesn't matter whether you specify radeon or ati as the driver name.

Check to make sure the monitor cable is properly seated.  Does the monitor go off/on at regular intervals?  It sounds like perhaps the monitor is gets woken up due to a temporary signal on the port.  I'll bet some process is polling the monitors at some set interval.  Usually it's upowerd or the kde equivalent.  Does killing upowerd fix the issue?  Those daemons shouldn't be polling the the connectors.  The kernel will provide events if a monitor is connected.

Ah, interesting: now that I'm using the radeon driver I'm getting the following
message being repeated in the kernel log whilst the display is cycling between
on/off states:

[  411.268512] [drm:atom_dp_get_link_status] *ERROR* displayport link status
failed
[  411.420475] [drm:atom_dp_get_link_status] *ERROR* displayport link status
failed
[  412.160477] [drm:atom_dp_get_link_status] *ERROR* displayport link status
failed
[  412.308462] [drm:atom_dp_get_link_status] *ERROR* displayport link status
failed
...and so on.

NB, In Debian, the "ati" and "radeon" drivers are seperate packages: you can install the latter without the former. I'm aware that the radeon driver is named the ati driver in the git sources.

Alex / Chris: I've dropped to single user mode, verified that nothing but kernel space processes & bash were running (with ps aux|grep -v "]") and run nothing but Xorg and an xterm & I still get the same behaviour. So it doesn't look like a user-space process is at fault.

(nb, I also tried just killing upowerd and that didn't make any difference either)

If I try a DisplayPort cable, I get no output whatsoever from X and a pile of errors in the kernel log. I guess that should go in another bug report though.

Unless the failure to correctly setup the DP port is what's causing the spurious DP hotplug IRQs which are triggering DP sync attempts which are in turn causing the CRTC to wake up the monitor of course! Bit weird that they only seem to happen when the DVI connected CRTC is suspended though.

Hi,

I'm having a problem very similar to the one reported by Phil Armstrong.

I'm running:
- Ubuntu 11.04 (Natty Narwhal)
- kernel 2.6.38-8-generic-pae #42-Ubuntu i386
- Loading Radeon driver through KMS/DRM (passing radeon.modeset=1 parameter to kernel)
- xserver-xorg 1:7.6+4ubuntu3.1
- xserver-xorg-video-ati/xserver-xorg-video-radeon 1:6.14.0-0ubuntu4
- ATI Mobility Radeon HD 5450 MXM Discrete Graphics Card
- Dell ST2420L monitor
- HDMI cable

When I try to suspend/off the screen (either by inactivity through gnome-power-manager, or using xset dpms force off) it gets into a cycle where it prints the "going to sleep" message repeatedly, the monitor is still backlit.

Workarounds that worked for me:
- Using "sudo vbetool dpms off"
- Using "xrandr --output HDMI-0 --off"
- Using the fglrx driver (without KMS/DRM of course)
- Using a VGA cable (this is the workaround I'm currently using)

The problem happens only with the xserver-xorg-video-radeon cable, either with or without KMS/DRM, and with the HDMI cable. The issue seems to be in the HDMI code and in the xorg driver (not the KMS one, or maybe it's on both?).

I found these messages in the dmesg output, but they don't match the times when I tried to suspend the screen so I don't think they are related (they might be though):

[  738.188630] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[ 1768.943075] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[ 2905.929263] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[ 2952.912733] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[ 6534.356949] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id

I'll attach some files (Xorg.0.log, lspci output, etc.) to help you diagnose the issue. Let me know if there is any test I can do for you, I'm willing to patch/compile/add traces to any components on my system as long as you can give me some hints on what I should be looking for...

Thanks!
Fil

Created attachment 48751 [details]
Fil's Xorg.0.log

Created attachment 48752 [details]
Fil's dmesg

Created attachment 48753 [details]
Fil's lspci

Any news on this bug? Can you please suggest some way I could try to troubleshoot this issue? I don't mind rebuilding any parts of the system in order to add instrumentation or to try possible fixes... The only problem is that I wouldn't know where to start (just to arrive to this point already took me quite a while)... Any suggestions on how to proceed with the investigation would be very appreciated.

Thanks,
Fil

Does the 3.0 kernel work any better?

I've discovered that resetting my monitor back to factory settings & telling it not to scan it's inputs but to stick to a specific input has made DPMS work for me.

I believe there's still an issue lurking here somewhere since with the previous settings Windows could still successfully put the monitor to sleep but Linux couldn't. I'll experiment with a few settings (and the 3.0 kernel) to see if anything makes any difference.

I think what's happening is that when the monitor scans inputs, it generates connect/disconnect signals on the hotplug pin when it switches to/from the input in use.  This generates an interrupt which in turn sends a hotplug event to userspace.  The X driver then gets the event and assumes the monitor is plugged/unplugged and attempts to turn the output on/off.  I'm not entirely sure how the windows driver handles it.  I suspect what we want to do is look at the rate at which plug/unplug interrupts are generated and wait to see how much time has elapsed since the previous event before actually generating an event for userspace.  If you are interested, the evergreen irq handler is evergreen_irq_process() in evergreen.c and the hotplug work handler is radeon_hotplug_work_func() in radeon_irq_kms.c in the kernel.

Or just ignore hotplug/unplug events if the output is supposed to be in a powered down state until the system decides to wake it perhaps?

I am seeing the same issue. I have three monitors, all the same model, connected to a HD5450, one via DVI, one via HDMI and one via DisplayPort.

"sleep 5; xset dpms force off" causes the DisplayPort connected monitor to sleep properly, while the DVI and HDMI connected monitors flash between a blank screen and a "Entering power save mode" message.

So the system is clearly trying to sleep and wake up monitors at the right time, because it works perfectly for the DisplayPort connected one, just the DVI and HDMI connected ones have the problem.

This is on a Debian wheezy system:

kernel: 3.0.0-1-amd64
xserver-xorg-video-ati: 6.14.2-1

Anything I can do to help debug this, please let me know.

thanks

paul

I have a similar issue, I think, with a Dell ST2420L monitor and a Radeon HD 5700 (monitor connected to the DVI-D port). xset dpms force off causes the backlight to turn off, but then the backlight turns on again every 10secs and the monitor displays the message "Entering power save mode" for a couple of seconds before the backlight turns off again.

The montior has an indicator LED. On windows when the screen is blanked, the indicator LED turns orange and the monitor does not turn on again. Similarly, if I use vbetool dpms off the LED turns orange and the monitor does not turn on again. It is only xset dpms force off that malfunctions.

The same thing happens if I do not start X. When the text mode console blanks, the monitor turns on every 10 seconds to flash the entering power save mode message.

My fix was to stop the monitor scanning it's inputs by turning off the automatic input detection. Not ideal, but at least it worked...

I tried that, didn't make a difference for me. If no kernel level fix is forthcoming, I guess I will have to write a custom screensaver that uses vbetool to turn the monitor off and on, if I can find the time.

I should note, in case it was not clear in my previous post, that xset dpms force off does not turn the LED orange, unlike vbetool and Windows.

Turning off automatic input detection (by manually configuring the input type) does not work for me either. This is with a Radeon HD 5450 and Dell U2211H via either HDMI or DVI, while via DisplayPort it works as expected.

xset dpms force off did lead to the monitor turning its LED orange & turning off for me; it would just promptly turn back on again. I presume this is a monitor firmware difference.

(In reply to comment #34)
> xset dpms force off did lead to the monitor turning its LED orange & turning
> off for me; it would just promptly turn back on again. I presume this is a
> monitor firmware difference.

It might also be a late inpute event coming in.  Try:
sleep 10; xset dpms force off
and see if that makes a difference.

Alex: See comment 2 :)

OK, to update this bug, with kernel 3.1.1 (Debian current release)

I used the command "sleep 10; xset force dpms off" to trigger dpms.

In single user mode, just udevd, Xorg, portmap and an xterm running:

  The guilty setting on my monitor appears to be "Auto Switch Input". With this on, X is unable to put the monitor to sleep at all; the screen goes black but the monitor remains on. With Auto-switch input off, dpms works fine.

With a Gnome desktop booted:

  With auto-switch on, I get the same behaviour as reported for single-user mode. With it off, I sometimes get the previously reported "sleep, then wake-up" behaviour, sometimes not. Killing upowerd doesn't make any difference. Presumably something else is waking the monitor up, but I can't work out what's making the difference: perhaps there's some internal monitor or graphics card state?

Meanwhile Windows is able to put the monitor to sleep permanently regardless of monitor settings on the same machine.

So this bug is still extant as far as I'm concerned.

Make sure your kernel has this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=73104b5cfe3067d68f2c2de3f3d4d4964c55873e

These might also be needed:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=d5811e8731213f80c80d89e980505052f16aca1c
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=cbac9543281f8e813f3ca9186c963a9b55136e93

It appears to be built from a very lightly patched 3.1 stable tree, which has all those patches.

I suspect what is happening is that the monitor's auto input switch polls all the connectors when when it polls the connector, it generates a hotplug event.  The kernel driver then sends an event to userspace and the xserver listens for the events and reacts by turning on the outputs.  Try commenting out:
drm_helper_hpd_irq_event(dev);
in radeon_irq_kms.c and see if that fixes the problem.  If it does, it's most likely a userspace problem.

Although you were probably asking Phil to do this, as I was rebooting my machine anyway, I commented out the line

drm_helper_hpd_irq_event(dev);

rebuilt the kernel and rebooted. (this is kernel version 3.1.1 gentoo patchset applied). Then ran

sleep 10s; xset dpms force off

The monitor LED remained white and the monitor turns on to flash the entering powersave mode message every ten seconds. Using vbetool continues to work correctly - i.e. the LED turns orange and the monitor does not turn on again.

Just wanted to chime in here as I'm having an identical issue with DPMS, the exact sequence for me is:

  1) Invoke "sleep 5; xset dpms force off"
  2) Display goes fully black, with backlight off, 2-4 seconds pass
  3) Backlight turns on, OSD pops up and says "DVI", a second or so passes
  3) OSD says "No signal", a second or so passes
  4) Go to 2

One interesting thing is that I have two identical displays (2 x Iiyama ProLite B2409HDS) where one is connected via DVI, the other is connected on the second DVI port but using a DVI->VGA(D-SUB) adapter. However, the DPMS problem only happens on the display connected on the DVI port, not the one that is connected with an VGA cable. With both displays connected and enabled (mirror mode), the VGA one turns off and stays off, the DVI one goes into the cycle described above when DPMS 'off' activates.

Trying with only one display connected via either DVI or VGA does not change anything; via DVI I get the DPMS cycle, via VGA it appears to work correctly.

Specs:

  Sapphire Radeon Vapor-X HD5850 1G GDDR5 Dual DVI-I/HDMI/DP
  libdrm from git master (adf1428915bfd0ee24758a3cbd56ce9b64f6eefb)
  xf86-video-ati from git master (eb6d769a087b2ed5952f477fc3f0b0625810a287)
  mesa from git master (1f125374e73d1718cd54c946826c76b09998c055)
  linux 3.1.6
  xorg-server 1.11.3
  gentoo

Turning off the display's 'Signal select: auto', explicitly setting it to 'DVI', doesn't seem to help in my case. I'll try the patch mentioned in previous comments as well. Also, setting "drm_kms_helper.poll=0" on the kernel commandline (something which chithead suggested on #radeon IRC) didn't help either

I only installed this card today to replace an NVIDIA gpu that didn't perform well under Gnome 3, so I'm not sure if this is some kind of regression. I do remember having this problem before when I had this card installed in another PC months ago, so I think this problem has been around for a while. I've not had this problem with the nvidia GPU, and I might try fglrx later to see if it happens there

I have the same problem with a Dell monitor and ATI graphics adapter
under a current ArchLinux distribution.


Red Hat seems to have resolved this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=714334

You should consider applying their patch.

I just realized that their suggested patch comes from upstream,
so it should already be applied since Oct 2011. Sorry.

However they still claim that this bug is fixed in their release,
which is based on 6.14.3

This appears to be fixed in the current version of the radeon driver I have installed which is 16.14.4