Bug 186956 - Suspend/resume fails on Thinkpad X40 using i810
Suspend/resume fails on Thinkpad X40 using i810
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-power-manager (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-27 13:05 EST by Eric Raymond
Modified: 2013-03-05 22:45 EST (History)
2 users (show)

See Also:
Fixed In Version: fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-03 17:27:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot of corrupted graphics (218.16 KB, image/png)
2006-04-02 21:15 EDT, Wade Mealing
no flags Details

  None (edit)
Description Eric Raymond 2006-03-27 13:05:16 EST
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 18:24:23 EST
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-02 21:13:37 EDT
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-02 21:15:43 EDT
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 00:51:26 EDT
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 08:47:40 EDT
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 14:41:53 EDT
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 05:21:49 EDT
(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 05:28:52 EDT
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 17:15:30 EDT
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 14:06:00 EDT
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 17:27:18 EST
Looks like this was fixed in fc5, and no recent activity to contradict this, 
so closing.

Note You need to log in before you can comment on or make changes to this bug.