Bug 186956

Summary: Suspend/resume fails on Thinkpad X40 using i810
Product: [Fedora] Fedora Reporter: Eric Raymond <esr>
Component: gnome-power-managerAssignee: David Zeuthen <davidz>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: mclasen, richard
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: fc5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-12-03 22:27:18 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 Flags
Screenshot of corrupted graphics none

Description Eric Raymond 2006-03-27 18:05:16 UTC
Description of problem:

Suspend/resume fails on Thinkpad X40 using i810 integrated graphics device.

Version-Release number of selected component (if applicable):

kernel-2.6.15, xorg-x11-server-Xorg-1.0.1

How reproducible:

Always.

Steps to Reproduce:
1. Key Alt-F4 to induce suspend.
2. Close and open lid to resume.
  
Actual results:

xorg's brains get scrambled; symptoms include (but are not limited to) wrong
backgrounds in xterms.

Expected results:

Normal X display resumes properly.

Additional info:

Also, lid close fails to trigger suspend as it should.

Comment 1 Eric Raymond 2006-03-27 23:24:23 UTC
The resume problem can be fixed by including "acpi_sleep=s3_bios"
to the kernel options in /etc/grub.conf (thanks to Dax Kelson for this tip).

That doesn't make lid-close do the right thing, though.


Comment 2 Wade Mealing 2006-04-03 01:13:37 UTC
Ok, Ive spent some time hacking on this.

Eric is correct, you need the acpi_sleep option for this to come back from sleep.


Although I still get the graphics corruption.  See attached screenshot.  This is
not reproducable 100% of the time.

It can not be fixed with change between VT's.  
It can not be fixed with an init 3, init 5.
It requires a reboot for X11 to return to normal usable mode.

The screenshot itself does not do justice to how the damage works.  When you
alt+tab things go back to normal, until you move a widget in which case the
screen "damages" again.

This reminds me of a badly behaving  application that doesnt repaint correctly,
although this is not the case in this situation.

Apologies for typos or incorrect sentence structure, I am typing this in the
damaged state.

Comment 3 Wade Mealing 2006-04-03 01:15:43 UTC
Created attachment 127219 [details]
Screenshot of corrupted graphics

This is an example of some of the damage, it gets much worse than this.

Comment 4 Wade Mealing 2006-04-04 04:51:26 UTC
If you want the lid close to work, I had to do this.

Make the file  /etc/acpi/events/lid.conf

event=button/lid
action=/etc/acpi/action/sleep.sh %e


In the /etc/acpi/action/sleep.sh file

do this.

#!/bin/bash

echo -n 'mem' > /sys/power/state

save, then 

service acpid restart

Close lid.. should resume assuming you have "acpi_sleep=s3_bios"
to the kernel options in /etc/grub.conf, it should come out.. albeit damaged.

Comment 5 Wade Mealing 2006-04-23 12:47:40 UTC
Ok,

Found that if you remove gnome-power-manager and just let the kernel do its
thing. Behavior seem to go back to normal. 

Comment 6 Eric Raymond 2006-04-24 18:41:53 UTC
I confirm that removing gnome-power manager fixes the display-trashing problem.
It also fixes an unrelated bug: pulling the plug on the machine sometimes threw
it into sleep mode.

Comment 7 Richard Hughes 2006-04-25 09:21:49 UTC
(In reply to comment #6)
> I confirm that removing gnome-power manager fixes the display-trashing problem.

Not sure why g-p-m would have anything to do with the display, but how do you
suspend without using g-p-m?

> pulling the plug on the machine sometimes threw it into sleep mode.

This is fixed in 2.14.2 (hopefully)

Richard.

Comment 8 Richard Hughes 2006-04-25 09:28:52 UTC
Eric, does the display corruption also happen when you use pm-suspend rather
than echo -n 'mem' > /sys/power/state ?

hal uses pm-suspend to do the suspend on fedora, and I think this is the root of
the problem. You may have to comment out the vbetool stuff in /etc/pm/* before
pm-suspend (and thus gnome-power-manager) will work.

Richard.

Comment 9 Fedora Update System 2006-04-26 21:15:30 UTC
gnome-power-manager-2.14.3-1 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 10 Fedora Update System 2006-05-04 18:06:00 UTC
gnome-power-manager-2.14.3-1 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 11 Nigel Cunningham 2006-12-03 22:27:18 UTC
Looks like this was fixed in fc5, and no recent activity to contradict this, 
so closing.