Bug 474296

Summary: Desktop Effects causes hang on resume from suspend to RAM with Intel 945GME graphics
Product: [Fedora] Fedora Reporter: Anthony Horton <anthony.horton>
Component: xorg-x11-drv-i810Assignee: Adam Jackson <ajax>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: christof, krh, opensource, pknirsch, rajeshmeena21, richard, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: 2.5.0-4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-21 18:41:00 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
pm-suspend.log from (the second half of) the 'double' suspend/resume with compiz disabled
none
pm-suspend.log from the suspend/resume attempt with compiz enabled, hung on resume
none
Extract from /var/log/messages for the period covering the tests described in my comment none

Description Anthony Horton 2008-12-03 02:24:19 EST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) Gecko/2008111217 Fedora/3.0.4-1.fc10 Firefox/3.0.4

Resume from suspend hangs indefinitely on an Asus Eee PC 901 (and presumably Eee PC 1000/1000H which is similar hardware).  The suspend appears to proceed normally, but on resuming the computer locks up.  The screen(s) is/are entirely black apart from a caret at the previous mouse cursor position.  No response to mouse or keyboard inputs, the only way to recover is to power cycle the machine.  On one occasion battery removal was required before the computer would boot again.

Reproducible: Always

Steps to Reproduce:
1. Suspend an Eee PC 901 to RAM (pm-suspend or GNOME Shutdown->Suspend).
2. Attempt to resume.
Actual Results:  
Blanks screens, completely unresponsive machine requiring hard reset to recover.

Expected Results:  
Resume to previous state prior to the suspend to RAM.

1. This is a regression from Fedora 9.  In Fedora 9 suspend worked for Eee PC 901/1000/1000H aside from the backlight brightness bug, https://bugzilla.redhat.com/show_bug.cgi?id=464260

2. This problem only occurs with suspend, hibernate appears to work correctly.

Version info:

pm-utils-1.2.2.1-2.fc10
kernel-2.6.27.5-117.fc10
Comment 1 Anthony Horton 2008-12-05 07:28:39 EST
It looks like compiz may be the cause of at least part of the problem. 

With a fresh, up to date Fedora 10 install I turned compiz off and tried another suspend.  Suspend appeared to work normally as it did before but this time when I tried to resume the resume appeared to be successful before immediately suspending again.  I pressed a key again and this time the laptop resumed apparently successfully.  I then attempted to re-enable compiz and the laptop immediately froze (corrupted display, no response to keyboard or mouse).  I could still ssh in from another machine and attempted to reboot it that way but while shutting down it hung completely and had to be power cycled.

After starting up again I checked that compiz was still disabled (it was) and tried another suspend/resume.  It still did the immediate resuspend on the first resume attempt, but on the second resume it seemed fine.  I've attached the pm-suspend.log from that attempt as pm-suspend.log.nocompiz.

I then rebooted the machine and re-enabled compiz (this time it didn't freeze).  Again suspend appeared to work OK, but when I tried to resume it froze with a blank screen, power light on and disk activity light on constantly.  No response to the keyboard or mouse and it didn't get as far as bringing the network back up so I couldn't ssh in.  I had to turn the use the power button to shut it down, but when I tried to turn it back on it just hung in the same blank screen all lights on state (it didn't get as far as the BIOS splash screen).  I had to remove the battery and then I was able to get it to reboot.  Once it was back up I looked at the pm-suspend log, but there's nothing after the suspend completes (I've attached it as pm-suspend.log.compiz anyway).

I've also pulled out the contents from /var/log/messages over the approximate time period covering the 'double' suspend/resume with compiz off, the reboot, and the suspend and hang with compix on.  I've attached this as messages.log.

Any ideas where the cause of the problem might be?  Is there any other information I can provide that might be useful?  This is a serious regression from Fedora 9 for users of this hardware (assuming others have the same problem).
Comment 2 Anthony Horton 2008-12-05 07:31:04 EST
Created attachment 325832 [details]
pm-suspend.log from (the second half of) the 'double' suspend/resume with compiz disabled
Comment 3 Anthony Horton 2008-12-05 07:34:26 EST
Created attachment 325833 [details]
pm-suspend.log from the suspend/resume attempt with compiz enabled, hung on resume
Comment 4 Anthony Horton 2008-12-05 07:39:15 EST
Created attachment 325836 [details]
Extract from /var/log/messages for the period covering the tests described in my comment
Comment 5 Anthony Horton 2008-12-09 01:32:48 EST
Confirmed the behaviour after a BIOS upgrade and fresh install.  Resume from suspend succeeds (apart from a wireless driver problem) with Desktop Effects disabled, but if Desktop Effects are enabled the the system will lock up on resume when trying to awaken X.  This is a regression from Fedora 9.

Given this I'm changing the component from pm-utils to compiz.  Should it be xorg-x11-drv-i801 instead, though?

https://bugzilla.redhat.com/show_bug.cgi?id=473307 looks similar, though with ATi graphics.
Comment 6 Anthony Horton 2008-12-11 19:28:36 EST
It seems that this is essentially the same issue as in https://bugzilla.redhat.com/show_bug.cgi?id=467332

Following the updates to xorg-x11-drv-i810, the kernel and the mesa packages (to versions 2.5.0-4, 2.6.27.7-134 and 7.2-0.14 respectively) the bug appears to have be fixed, resume from suspend to RAM now succeeds with compiz enabled.
Comment 7 Christof Damian 2008-12-12 15:42:35 EST
I don't know which update fixed it, but it does work for me now on a EeePC 901 with a Intel Corporation Mobile 945GME
Comment 8 Matěj Cepl 2008-12-21 18:41:00 EST
Let's say it really is intel driver. Thanks for letting us know.
Comment 9 Rajesh 2009-05-15 23:02:45 EDT
yes, i was sick of this issue, but latest kernel update solved this issue for me.. thanks a ton.