Bug 466995
| Summary: | resume and unhibernate both produce corrupt graphics | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thomas J. Baker <tjb> | ||||||
| Component: | xorg-x11-drv-i810 | Assignee: | Adam Jackson <ajax> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | rawhide | CC: | mcepl, peter.hutterer, pix, xgl-maint | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-11-12 13:59:19 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Thomas J. Baker
2008-10-15 00:09:54 UTC
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 *** |