As the summary states, once the screen enters sleep mode, and effectively turns off, I am unable to turn it back on. I have to kill the power to the system to get it to come back on. I can still SSH into it, so I know that the computer itself is working. At first, I was not sure what was causing it. Initially when it sat idle for a while, it would just appear to have stopped working. Well, eventually I started thinking it had something to do with power management issues, so I disabled the screen from sleeping, and just kept it so my screen saver would run. Ever since then, I have had no issues. However, I wanted to do some further diagnosing, and I've been able to manually reproduce it. $xset dpms force off Once I do that, I can't get the screen to turn back on for the life of me. On my other machine, which is running 11.0, when I do that, all I have to do is move the mouse and it turns back on. I also figured that as long as the terminal window in the background was the window in focus, that I could just turn it back on by running: $xset dpms force on That did nothing for me though. I still can't get it to turn back on. /EEEPC 1000 //Intel Video Card ///OpenSUSE 11.1 Beta 2
Please attach Xorg.0.log.
Created attachment 19636 [details] Xorg log This is before I even attempt to turn off my screen. I should also mention that this bug does not _always_ affect me, but it seems to show up majority of the time.
Seeing the same here on my Lenovo notebook with i965 graphics. This did not happen with openSUSE 11.0.
"xset dpms force off" works fine for me btw (meaning the screen comes back after moving mouse or pressing a key just fine)
Since Kent asked me about the severity/priority.
I'm not sure, but this may have something to do with Compiz. Granted it's only been since this morning that I disabled it, when the screen shuts off now, I can get it to come back on. Having said that, there were a few times when Compiz was enabled that it would work just fine, so I don't know. Before I disabled Compiz this morning though, I let my screen turn off, and I was unable to get it to turn back on.
Michael, you said this behavior was a regression for you; openSUSE 11 had xf86-video-intel 2.3.1, when did you start seeing the behavior (i.e. what version is in 11.1 Beta 2)? And is the screen completely off or does it look like the backlight comes on but nothing actually displays?
It would have to have been a regression for me too. OpenSUSE 11.0 never had this problem. Michael, you using Compiz by any chance? /Using OpenSUSE Beta 4 / RC 1 now. (Somewhere in-between) //Beta 4 / RC1 seems to use 2.5.0
I will need to do a new openSUSE beta installation because my current is broken. Hopefully I will get the time soon. That said, I was using compiz at the time. I will test with metacity.
I just woke up, and this bug is occurring again. There are a few things I wanted to test, which may or may not help figure out what is going on. 1. Connecting to the machine with SSH with X forwarding works. ( `ssh -X` ) I've been able to launch Pidgin. 2. Trying to open up VNC however, does not work. It successfully connects to the server, but it dies before it asks for a password. By it dies, I mean, it just sits there and does not get as far as the password. 3. `init 6` give me no activity when I type it in. Nothing happens. 4. In order to restart, I have to use `/etc/init.d/reboot`. That does not reboot completely correct though. 5. When it does restart, the screen brightness (at the BIOS and after) is _extremely_ dark, and unless I change it right after the boot loader / before X loads, it stays that way. Scared me the first time it happened, as I thought I broke something... 6. If I do a `ps`, I get all the applications that were running under X. 7. I appear to be able to successfully kill the applications that were running in X without `kill -9`. `kill` works fine. 8. Restarting XDM did not help at all. `/etc/init.d/xdm restart` A little bit more random... 9. ALSA seems to die. I was trying to get aplay to play a tune so I could figure out how dead my machine really is. After reloading ALSA, I can still use it to play tunes. That's all I can think to try at the moment.
Using only metacity on openSUSE 11.1b5 I have _not_ seen any problem with this.
Beta5 is released with Intel Graphics Q3 release. Before that release,, you have to go to Novell repository to patch all the related graphics packages.
We finally figured out what's the issue is here. Apparently GNOME uses 'xrandr --output LVDS --off' for screen blanking (instead of DPMS) and this hangs the Xserver in drmWaitVBlank() when compiz is running. Disabling vblank fixes/workarounds the issue. This could be reproduced at least on 945GM and 945GME (any Netbook).
Nice work Stefan!
Oh, that's good to know, thanks Stefan. It sounds like the GNOME/Compiz integration needs to be a bit smarter; vblank interrupts definitely won't work (and aren't expected to work) on displays that get turned off. Unfortunately, there's no easy way for the kernel to tell when the display is about to be disabled; all it knows is whether a client is currently using vblank events. Once we have kernel mode setting, the kernel will know if there are waiting clients and when modes are programmed, so we can at least print a warning in this case, or reject the display disable call. But at any rate, I'm going to mark this NOTOURBUG, since waiting for vblank on a disabled display is definitely not something we can fix.
Created attachment 20569 [details] [review] Don't wait for vblank while CRTC is 'in modeset' This patch might help, if the display driver calls the DRM_IOCTL_MODESET_CTL ioctl with _DRM_PRE_MODESET before disabling the CRTC and with _DRM_POST_MODESET after enabling it.
Yeah, that patch looks pretty good. I think there's still a race between a thread waiting on a vblank that hasn't arrived and the pipe getting turned off, though we might be able to put a wakeup of the vbl_queue in the POST_MODESET path to deal with that. Another option would be to decrease the timeout. 3s is both too long for the typical waiter, and too short if you're waiting for a vbl sequence that's far away...
(In reply to comment #17) > I think there's still a race between a thread waiting on a vblank that hasn't > arrived and the pipe getting turned off, Good point. > though we might be able to put a wakeup of the vbl_queue in the POST_MODESET > path to deal with that. I'm afraid that won't help, as the sequence number may not be appropriate to end the loops of existing waiters. > Another option would be to decrease the timeout. 3s is both too long for the > typical waiter, and too short if you're waiting for a vbl sequence that's far > away... The problem is that for the X server, I think the timeout would need to be shorter than 20ms or something like that, otherwise the ioctl always gets interrupted by the smart scheduler SIGALRM. I think that would be too short for all legitimate uses of the ioctl though. Maybe what we should do instead is to keep track of time in drmWaitVBlank() and break out of the loop after 1s or so. At any rate, it seems clear that this is something that should be addressed either in the DRM or in libdrm, so I'm reopening.
Is it possible when you make LVDS or others display off, you can cleanup the vblank. That will tell others application that, we disable vblank, don't wait any more.
Created attachment 21574 [details] [review] timeout after 1s waiting for vblank I can't reproduce this problem with xset dpms force off, but maybe my compiz is configured differently. Here's a patch that should timeout the vblank wait after a second if we're getting interrupted. You may also want to check out the patch in #18879, it fixes a similar issue with current bits.
Posted the patch for this to dri-devel, hopefully we'll be able to push something like it soon.
Fixed by f4f76a6894b40abd77f0ffbf52972127608b9bca.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.