Since the upgrade to kernel 2.6.27 release version, my intel graphics won't resume correctly. From either suspend or hibernate, I get a black screen with a little box of corrupt random colors around the cursor. I can move the mouse around and it's drawn correctly but the unlock dialog never appears and I can't switch to other VTs, almost like the keyboard doesn't work at all. I can't say exactly if this started with the switch to 2.6.27 proper from the preleases because several previous kernels didn't work for me (I missed the info about the ext4dev to ext4 transition and kept running an old kernel) and when I finally got kernel-2.6.27-3.fc10.x86_64 to boot, suspend/hibernate was broken. The update today to xorg-x11-drv-i810-2.4.2-10.fc10 didn't help. I'm not sure I can get into the machine after resuming (via network to view logs) but I can try if need be. Perhaps you're already aware of this problem.
I updated to kernel-2.6.27-13.fc10.x86_64.rpm, kernel-firmware-2.6.27-13.fc10.noarch.rpm, and xorg-x11-drv-i810-2.4.2-12.fc10.x86_64.rpm this morning because I saw some possible fixes. Now on resume, I get a black screen with the cursor drawn but I can't move the cursor and no other graphics. I can push the power button for a clean shutdown. I run without an xorg.conf file and I'll include the X log next.
Created attachment 320435 [details] /var/log/Xorg.0.log.old
why Xorg.0.log.old, why not the current one?
After the graphics locked up I had to reboot, which made a new Xorg.0.log that didn't contain the pertinent errors. The old one did. I am still having the problem today with an up to date rawhide installation. In fact, it's a bit worse now as when I try to reboot, the machine locks up with flashing numlock and caps lock lights.
After todays updates I did a suspend just to try to see if anything better got logged. After resuming, X was locked up completely. I couldn't move the mouse or anything. I was able to ssh in and nothing seemed to be logged initially. I then got distracted by something else. After a good 15 minutes or so, X came back (restarted?) and is working fine. I'll include the Xorg log next.
Created attachment 321947 [details] Xorg.0.log
I still don't get a clean resume with the kernel-2.6.27.4-79.fc10.x86_64 kernel. I've not been able to repeat the extremely long graphics resume from #5 and I've tried a couple of times. I just tried a suspend/resume and I get a black screen with a multicolor box around where the cursor first appears. I can move the cursor but the keyboard doesn't light the capslock key. As another test, I just plugged in an external USB keyboard and it is similarly non-responsive even though dmesg shows the usb subsystem configuring the device. (I can get onto the laptop via the net.) Is there a way to test if this is an evdev problem and not so much an intel one?
Another note. If I remote login and setenv DISPLAY:0.0 and then run xrefresh, it hangs instead of completing instantly. I don't know if this is caused by the screen being locked or not though.
I just got back from lunch and the xrefresh I described in comment #8 completed. The keyboard is now working and the graphics are back. What's in the log file after the resume and after it comes back to life is this: (II) AT Translated Set 2 keyboard: Device reopened after 1 attempts. (II) Sleep Button (CM): Device reopened after 1 attempts. (II) Video Bus: Device reopened after 1 attempts. (II) Power Button (CM): Device reopened after 1 attempts. (II) Video Bus: Device reopened after 1 attempts. (II) Video Bus: Device reopened after 1 attempts. (II) Macintosh mouse button emulation: Device reopened after 1 attempts. This looks more like an evdev thing. Does anyone know what the timeout to retry is?
Option "ReopenAttempts" "integer" Number of reopen attempts after a read error occurs on the device (e.g. after waking up from suspend). In between each attempt is a 100ms wait. Default: 10. If you're exceeding the timeout/retries, then you should have a message in the log about it.
I don't have any other messages than what I posted in #9. It logged that it reopened it after one attempt which should have been 100ms but was over 30 minutes of real time. I'm not running out of attempts, it's just taking a long time to execute the first reopen attempt, which seems to work.
I don't know if it's related but KP posted a patch related to suspend/resume on intel hardware to the xorg list: http://lists.freedesktop.org/archives/xorg/2008-November/040106.html
Your bug (that i appear to have too) seems to be the bug 467332 one, do you also use compiz, by chance ?
Yes, I'll close as dupe. *** This bug has been marked as a duplicate of bug 467332 ***