ThinkWiki - User contributions [en]

Talk:Problem with display remaining black after resume

2010-11-20T22:55:14Z

Jbs: /* Windows too */

== Screen went blank at resume with Windows XP too ==
Same symptoms with a ThinkPad running windows (one time, still stuck)
Any ideas to try?

== T43 with Intel Graphics Media Accelerator ==

It seems there are several possible solutions for this issue:

I tried 'Option "VBERestore" "yes"' as hinted in X41 section below, and this worked for me on my T43/915GM.

My T43 (1871-FYG) with Intel 915GM is also affected by the problem and the 'ATI' sollution with
acpi_sleep=s3_bios works. Please consider updating the page (I don't dare to do it myself).

== From my experience, this does not work with TP R50e. ==

If you want to be able to resume, you need :
* To start from a VT
* No option acpi_sleep
* to save the PCI state like:
cat /proc/bus/pci/00/02.0 > /var/cache/video.config
* Once you get back, restore it:
cat /var/cache/video.config > /proc/bus/pci/00/02.0

However, the X screen is not clean after the restore, so this is not very useable...

== The comment on R50e ==

There is a comment at the end of the page on R50e, saying that you should switch to console first, and look at a page to learn how to do this.

However. it seems to me that the given script already does it. Should the comment be removed?
----
The scripts are different. However, if you can approve that the solution provided on this page resolves the problem, please remove the footnote.

[[User:Wyrfel|Wyrfel]] 14:46, 17 Oct 2005 (CEST)
----
On my R50e, the script on this page works fine, while the one linked in the footnote quickly wakes up from sleep.

[[User:Thisnukes4u|Thisnukes4u]] 19:39, 1 Jan 2006 (CET)

== Problems with R51 and Intel Graphics ==

The problems described on the page occur intermittently
with an Intel Graphics card on an R51. Here is what happens:

1. One some occassions everything seems to work fine.

2. On other occassions the screen looks OK but the some plane seems to have vanished. New text on the screen overwrites instead of replaces prior text. The "standard" pattern disappears from the X background.

3. On yet other occassions the X server dies and comes out "blank" in the mode (2) above.

4. The above problems appear only with the "i810" driver. The "vesa" driver works fine. Moreover, if the machine is "suspend-to-disk"ed then the problem disappears on resumption once the X server is killed and re-started.

But for 1 and 4 above I would have given up and either avoided suspend to ram altogether or used vesa mode---as it stands the problem is tantalising.

Kapil kapil at imsc dot res dot in

== X30 ==

The {{bootparm|acpi_sleep|s3_bios}} boot parameter did the trick, no additional scripts required (Ubuntu feisty).

== X31 ==

In addition to the s3_bios trick, i needed to uninstall the uswsusp and hibernate packages. I've put all the details in the [[Category_talk:X31|X31 talk page]]. [[User:TheAnarcat|TheAnarcat]] 18:50, 14 July 2007 (UTC)

== X40 with an Intel 855GM Integrated Graphics Device ==

I used the {{bootparm|acpi_sleep|s3_bios}} boot parameter and the following ACPI script:

#!/bin/sh
set -e

vt=`fgconsole`
chvt 12
echo mem >/sys/power/state
vbetool post
chvt $vt

The {{bootparm|acpi_sleep|s3_bios}} boot parameter alone did not fix things, and neither did saving and restoring the information from {{path|/proc/bus/pci/00/02.0}}.

This is confirmed to work on my Thinkpad X40, running Arch Linux, kernel 2.6.24-rc2-git2, and ratpoison. This is also works even if framebuffer is enabled. This method also works on a Thinkpad X40, running Sidux, kernel 2.6.23.9-rc1, Compiz Fusion, and KDE.

To get suspend working on a Thinkpad X40, running Ubuntu 7.10, kernel 2.6.24-rc3, you need to do the following:
1) add Option "VBERestore" "true" to /etc/X11/xorg.conf
2) boot with "acpi_sleep=s3_bios"
3) edit /etc/default/acpi-support and uncomment the line about saving the video state on resume

After this it works from gnome-power-manager

The easiest way to get suspend working on a Thinkpad X40 running Debian Sid (as of November 26, 2007) is to install the uswsusp package, boot with acpi_sleep=s3_bios, and then use the command "s2ram -f -s -p -v"

:I got my X40 working with {{bootparm|acpi_sleep|s3_bios}} only. I've got the intel drivers 2.9.0 (using UXA), xorg 1.6.3 and kernel 2.6.31. --[[User:A76b034a|A76b034a]] 21:29, 30 September 2009 (UTC)

== X41 with an Intel 915GM Integrated Graphics Device ==

It works with the {{bootparm|acpi_sleep|s3_bios,s3_mode}} boot parameter. Resume works great, both on the VESA console and in X.

:Interesting--that didn't work for me. I needed to do several things to get it to work. First, I used s3_bios, but not s3_mode. Secondly, I had to edit resume_video() in /etc/pm/functions-intel to comment out the VBE post and restore. Those two changes made it functional, but the improper lid state in the HAL daemon caused it to go back to sleep just as soon as it resumed upon the lid opening, so I added a HAL restart to the front end of /etc/acpi/actions/sleep.sh. This means that I have to restart gnome-power-manager, too. I haven't yet figured out a way to do that in sleep.sh; currently I do it manually. I'll post this to the main page soon, unless I hear comments to the contrary. [[User:BrianTung|BrianTung]] 19:52, 30 April 2006 (CEST) (fixed a little)

:(gsaito): I used the {{bootparm|acpi_sleep|s3_bios,s3_mode}} boot parameter and it worked perfectly, entering Suspend to RAM and resuming perfectly. No more blank screens after resuming. No need for any other change as described above, at least in my case. I also have an X41 with Intel 915GM graphics adapter. I use OpenSUSE v.10.0.

I read the edit by Uberpenguin and tried the stated fix. No go: The next time I pulled out the adapter after a resume--boom, the machine goes straight back to sleep again. Evidently, the suggested workaround does not work on all machines. [[User:BrianTung|BrianTung]] 19:54, 22 June 2006 (CEST)

Yesterday I tried adding 'Option "VBERestore" "yes"' to the Driver section in xorg.conf on my X41 and it works great. I used no boot-params or anything else. The distribution is OpenSuSE 10.1. If anyone can acknowledge to my experience, I'd like to add this solution to the articles in this wiki. [[User:Sirmoloch|Sirmoloch]] 11:49, 4 July 2006 (CEST)

== Z60t with an Intel 915GM Integrated Graphics Device (PCI Express) ==

It works with the {{bootparm|acpi_sleep|s3_bios}} boot parameter. Here is the script I use (gentoo). Note: stopping and starting WiFi is not necessary to resume, but it is dead on resume until restarted and the module is reloaded. This is on a 2.6.15.4 kernel with framebuffer console support. The blinking led thing is a nice touch I got from the hibernate-scripts package - it blinks the sleep led (moon icon) until the sleep or resume cycle is finished.

The 'vbetool vbemode get/set' commands are for saving and restoring the console text mode - otherwise the screen becomes garbled.

#!/bin/bash

# blink sleep led (if ibm_acpi is installed)
echo 7 blink > /proc/acpi/ibm/led

# change to console 10 (unused?)
FGCONSOLE=`fgconsole`
chvt 10

# save video state
VBEMODE=`vbetool vbemode get`
cat /proc/bus/pci/00/02.0 > /tmp/video_state

# sync filesystem
sync

# sync hardware clock with system time
hwclock --systohc

# stop networking (atheros chipset)
/etc/init.d/net.ath0 stop
rmmod ath_pci

# go to sleep
sleep 2 ; echo -n 3 > /proc/acpi/sleep

# blink sleep led
echo 7 blink > /proc/acpi/ibm/led

# restore system clock
hwclock --hctosys

# restore video state
vbetool vbemode set $VBEMODE
cat /tmp/video_state > /proc/bus/pci/00/02.0

# change back to X
chvt $FGCONSOLE

# restart networking
modprobe ath_pci
/etc/init.d/net.ath0 start

# clean up behind us
rm /tmp/video_state
echo 7 off > /proc/acpi/ibm/led

== Fedora Core 5 ==

The vbetool on the article page worked great for me, but NetworkManager would not bring the wireless interface back up. I had to add "ath_pci" to the SUSPEND_MODULES variable in /etc/sysconfig/pm.

== R50e 1834-S3G in Debian Etch ==

I found it necessary to add a {{cmdroot|clear}} to the script before {{cmdroot|chvt}} 'ing back to VT7 after wakeup. If I didn't, I would end up with a 99% black corrupted screen in X.
[[User:Ris|Ris]] 18:38, 30 October 2006 (CET)

== Work-arounds for X60s / Intel 950 ==

The page identifies X60s's as having problems with blank display on resume (and I can confirm), but doesn't suggest a work-around. (Nor are there any obvious fixes for this boxes Intel 950 graphics card.) Has anyone gotten it working? [[User:Johnh|Johnh]] 06:47, 16 November 2006 (CET)

My error, the chip is really an Intel 945, and the suggested work-around of acpi_sleep=s3_bios works great! [[User:Johnh|Johnh]] 05:42, 17 November 2006 (CET)

== T60 with intel video card 945 ==

Linux: Gentoo, kernel 2.6.17
I have problem with black display after resume with active framebuffer (vesa or vesa-tng).
I have a lot of garbage after resume with active fb and acpi_sleep=s3_bios,s3_mode parameter.
And I have normal screen without fb and with acpi_sleep=s3_bios,s3_mode, but I cant operate with console.

Any ideas?

== T60 with intel X3100 and integrated usb cam ==

System:
*ThinkPad T61 (7659-Y7H) with Intel X3100 and integrated usb cam running Ubuntu Hardy (kernel 2.6.24-10-generic)

Problem:
*ThinkPad automagically resumes 3 seconds after suspend!
*Has a black screen after resume (no backlight/image or no backlight).

Workaround for black screen:
*Switching to tty1 and back to tty7 (where X is running) several times brings back display

Solution to both problems (both caused by integrated usb cam!?):

before suspend:
rmmod ehci_hcd
after resume:
modprobe -i ehci_hcd

[[User:E rulez|E rulez]] 21:20, 26 February 2008 (CET)

== Blank Screen on resume on W500 ==

If you experiment with different configurations, especially different video drivers (fglrx, radeon, radeonhd), please be advised that the fglrx module needs to be blacklisted if you want to use radeon or radeonhd. If fglrx is loaded upon suspend you will experience the blank-screen problem on resume.

Problem with display remaining black after resume

2010-11-20T22:52:37Z

Jbs: /* Affected Operating Systems */

There has been a problem encountered where the display stays black on resuming from suspend.

The symptom might have you think first that your system hang up, but you will realize that your ThinkPad works and you can even reset it via {{key|Ctrl}}{{key|Alt}}{{key|Del}}.

==Affected Models==
*ThinkPad {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}, {{T60}}, {{T60p}}, {{T61}}, {{T61p}} {{T410s}}
*Thinkpad {{T23}}
*ThinkPad {{X21}}, {{X30}}, {{X31}}, {{X40}}, {{X41}}
*ThinkPad {{R31}}, {{R50e}}{{footnote|1}}, {{R50p}}, {{R51}} (with BIOS 1.11), {{R52}}, {{R60}}, {{R61}}
*ThinkPad {{A30p}}
*ThinkPad {{390X}} (doesn't wake up; LCD backlight on, harddrive light remains on)
*ThinkPad {{Z60t}}, {{Z60m}}, {{Z61m}}, {{Z61e}}
*ThinkPad {{X40}}, {{X60s}}, {{X60}}, {{X61}}, {{X61s}}, {{X200}}, {{X200s}}, {{X201s}}

==Affected Operating Systems==
*Linux (it's a kernel issue)
*FreeBSD (6.x at least)
*Windows XP

==Solutions==
===Quick workaround for R61i, T23, maybe others===
Try pressing CTRL+ALT+F1 to switch to text console. The backlight should come on normally. Press CTRL+ALT+F7 to return to X.

This solution is not working on R61i using Debian Squeeze.

On a T23 using Ubuntu Feisty, pressing Fn+F7 (external/internal display change) once or twice brought the display back. After upgrading to Ubuntu Gutsy it doesn't work anymore, but pressing Fn+F3 (blank screen) and Fn (restore display) works.

===Quick Workaround for R61 (at least 8918-5QG) using NVidia===

Use Vesa driver instead of the proprietary NVidia driver.

===Quick Workaround for T61 (at least 7662-CTO) using NVidia Quadro NVS 140===

Try pressing Fn+F4 to get the OS suspend to RAM. Nothing on the screen will indicate that the OS is being suspended except for the Sleep LED. Wake up the OS by pressing the Fn key. This induces an additional 5-10 seconds of work. But this has consistently worked with no issues.

===Pseudo-solution for R61===
On an R61 running Fedora Core 9, the nv driver fails to turn the backlight on after resuming from a suspend to RAM. I fixed this by using the proprietary NVIDIA Linux drivers (v177.82).

=== Solution for ThinkPad Z60t ===

* '''Display controller:''' Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
* '''Distro:''' Fedora release 7 (Moonshine)
* '''Kernel:''' Linux 2.6.22.5-76.fc7

The solution is straight forward - just to add configuration parameter for the default '''pm-utils''' package. Create file <code>/etc/pm/config.d/config</code> and put there one line <code>DISPLAY_QUIRK_S3_BIOS="true"</code>, or execute following command:

echo DISPLAY_QUIRK_S3_BIOS=\"true\" >> /etc/pm/config.d/config

===Semi-Solution for ThinkPad X60 with damaged system after s2ram usage===
It happend when restarting a s2ram-session.

'''Symptom:''' Black screen with blinking "_" sign remaind. (without the ")

'''System status:''' HDD idle, fan running, everything else looks to wait for something to happen.

'''Semi-Solution:''' Booting with DVD-ROM and going through the installations menu,
where you choose "other" and "boot a installed system" (something like that). Gladly it works,
and OpenSuSE 10.1 comes up with 50% "failed" messages! I than shutdown properly, rebooted again
and had 100% "done" again, with no other things affected.

'''Further:''' Repairing with the DVD-ROM crashed massivly(!), so I selected "boot a installed system" as final
solution and it worked!

'''Unknown:''' Maybe the Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM will help,
because X60s and X60 are very familiar. (Not tested so far.)

(If this Problem is not right here, please edit and move.)

===Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM ===
see [[1400x1050 on Intel 915GM]].
===Solution for ThinkPads with ATI graphic chips and Intel 915/945GM ===

Affected models include {{X41}}, {{X60s}}, {{X200s}}, {{R60}} and {{T60}}.

This soluton also applies to T42 with Intel 855 and ATI 9600 M10.

One solution may be to provide the {{bootparm|acpi_sleep|s3_bios}} kernel parameter in your kernel parameter line.

For grub this would look like this:

title Linux, kernel 2.6.11-1-686
root (hd0,0)
kernel /boot/vmlinuz-2.6.11-1-686 root=/dev/hda1 ro acpi_sleep=s3_bios
initrd /boot/initrd.img-2.6.11-1-686
savedefault
boot

For lilo it would look like this:

image=/boot/vmlinuz
append="acpi_sleep=s3_bios"

The actual process of going to sleep is then managed through a sleep script; as a start, see the {{path|sleep.sh}} script in the Extreme Graphics 2 section below, but note the following comments:

In [[:Category:OpenSUSE|OpenSUSE]] 10.1 (at least on a T43p), it's necessary to override the default options for s2ram if you're using the newer ATI driver. This can be done putting {{bootparm|SUSPEND2RAM_FORCE|"yes"}} and {{bootparm|SUSPEND2RAM_ACPI_SLEEP|"3"}} in {{path|/etc/powersave/sleep}}.

In {{Ubuntu}} or {{Kubuntu}}, it may be necessary to modify {{path|/etc/default/acpi-support}}. In that file, make sure that {{path|ACPI_SLEEP}} is uncommented and set to true. With ATI chips, also make sure that {{path|SAVE_VBE_STATE}} is uncommented and set to true; with Intel chips, on the other hand, ensure that nothing is done with respect to VBE--no reposts, no state saves. Also commenting POST_VIDEO may help.

In {{Fedora}}, it may be necessary with the Intel chips to edit the {{path|resume_video()}} function in {{path|/etc/pm/functions-intel}} to comment out the VBE post and restore. (As of FC6 these seem to be pre-commented out.) Also, the laptop, after waking up, may go back to sleep immediately or whenever the AC adapter is disconnected. When this happens, it's caused by a bug in the HAL daemon that incorrectly reports certain ACPI events. This is a known problem and a simple workaround is described [http://live.gnome.org/GnomePowerManager/Faq#head-b8b1280115b0a51c2cc27b13a57121130ebf36cb here].

{{NOTE|It is possible this method will not work if the laptop is docked. It is also possible that the cited workaround for the HAL daemon bug will not work on some machines. A kludgier workaround in this event is to kill the HAL daemon on suspend. This necessitates the resuscitation of GPM upon resume.}}

Another solution is to use vbetool. If you are using {{Debian}} with the hibernate package, uncomment "EnableVbetool yes" in {{path|/etc/hibernate/hibernate.conf}} (or {{path|/etc/hibernate/ram.conf}}).

----

On '''T60 2007-CTO''' (Core2Duo 2Ghz, 2GB Ram, ATI X1400) the screen stayed blank after suspend-to-ram until I set '''vga=0''' in lilo.conf.

Working config:
Linux 2.6.21.5
fglrx 8.37.6
debian etch:
powersaved 0.14.0-5:
UNLOAD_MODULES_BEFORE_SUSPEND2DISK="usb_storage ohci_hcd uhci_hcd ehci_hcd ipw3945 pcmcia yenta_socket rsrc_nonstatic pcmcia_core"
UNLOAD_MODULES_BEFORE_SUSPEND2RAM="usb_storage ohci_hcd uhci_hcd ehci_hcd ipw3945 pcmcia yenta_socket rsrc_nonstatic pcmcia_core"
hibernate:
SwitchToTextMode yes
lilo.conf:
vga=0

"EnableVbetool yes" and other suggestions didn't work for me.

For suspend-to-disk, don't load fglrx in initrd.

----

On '''T60-20076RG''' (Core2Duo 2GHz, ATI X1400) with {{OpenSUSE}} 11.1 and fglrx 8-12 the following had to be done to get suspend to RAM always resume:
* Add {{bootparm|S2RAM_QUIRKS_SOURCE|"s2ram"}} to file {{path|/etc/pm/config.d/config}}
* Create an executable script {{path|/etc/pm/sleep.d/00text}} containing:
#!/bin/bash

case "$1" in
hibernate|suspend)
/bin/chvt 1
;;
thaw|resume)
/bin/chvt 7
;;
esac

There seems to be a bug ([https://bugzilla.novell.com/show_bug.cgi?id=463434 Novell bugzilla]) which makes it impossible for s2ram to switch to text console while suspending through pm-suspend. The script above forces console change. Along with setting s2ram as quirks source (which makes it correctly set acpi_bios before suspend - to s3_bios,s3_mode
for T60 2007*) this can make resume work flawlessly despite using vesafb.

===Solution for ThinkPads with Intel Extreme Graphics 2===
{{NOTE|
On [[:Category:X40|X40]]s/[[:Category:X41|X41]]s - even with Intel Extreme Graphics - and for [[:Category:R52|R52]]s with Intel Graphics Media Accelerator 900 the [[Problem with display remaining black after resume#Solution for ThinkPads with ATI graphic chips|solution for ATI graphics chips]] above is reported to work. In this case, make sure no changes to VBE are made, especially no state saves and no reposts.}}

The following solution should work on 865G, 865GV, 855GM, 855GME, 852GME chipsets.
*First of all, '''do not''' use the {{bootparm|acpi_sleep|s3_bios}} kernel parameter.
*Second, completely remove framebuffer support from your kernel. If it's built as modules, it is important that they do not get loaded at all.
*Before suspending, change to a console and safe the video state with {{cmdroot|cat /proc/bus/pci/00/02.0 > /tmp/video_state}}.
*On resume, restore the video state with {{cmdroot|cat /tmp/video_state > /proc/bus/pci/00/02.0}} and change back to X.
*For Debian Etch 4.0 on R50e just make following changes to /etc/default/acpi-support:
#SAVE_VBE_STATE=true
#VBESTATE=/var/lib/acpi-support/vbestate
#POST_VIDEO=true
SAVE_VIDEO_PCI_STATE=true

*For a R50e the only thing needed to make suspend to ram work in Ubuntu 6.06 is adding
Option "VBERestore" "yes"
to the <tt>Device</tt> section in your {{path|/etc/X11/xorg.conf}}, and the example script below.

The following example {{path|/etc/acpi/actions/sleep.sh}} script shows how to integrate the according lines.

#!/bin/bash

# change to console 1
FGCONSOLE=`fgconsole`
chvt 6

# safe video state
cat /proc/bus/pci/00/02.0 > /tmp/video_state

# sync filesystem
sync

# sync hardware clock with system time
hwclock --systohc

# go to sleep
echo -n 3 > /proc/acpi/sleep

# waking up
# restore system clock
hwclock --hctosys

# restore video state
cat /tmp/video_state > /proc/bus/pci/00/02.0

# change back to X
chvt $FGCONSOLE

# clean up behind us
rm /tmp/video_state

With Ubuntu 6.10 on a [[:Category:R51|R51 (2887-32G)]] I ''just'' (as none of the other tricks above) had to add {{bootparm|fb|false}} to the kernel line in {{path|/etc/grub/menu.lst}} and edit {{path|/etc/defaults/acpi-support}} this way:

SAVE_VBE_STATE=false
POST_VIDEO=false
SAVE_VIDEO_PCI_STATE=true
USE_DPMS=false
DOUBLE_CONSOLE_SWITCH=false

===Solution for ThinkPads with Intel I830 Chipset===
The following solution worked for me on an X30 with I830M chipset with kernel >= 2.6.16.

it *almost* works on my T400S (intel mobile 4 integrated graphics) and kernel lenny-2.6.30-amd64, but see below for better solution. (sometimes, it doesn't wake up at all, probably because some kernel modules unrelated to video don't like this suspend method. once, i had to restart gdm. i am using a weird setup if two gdm sessions on two virtual terminals, don't know if that's required to reproduce the latter problem.)

this works with vesafb and also with intelfb frambuffer support.

The following example {{path|/etc/acpi/actions/sleep.sh}} script shows how to integrate the according lines.

#!/bin/bash

FGCONSOLE=`fgconsole`
chvt 8
sync
hwclock --systohc

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

hwclock --hctosys
vbetool post

if [ "$FGCONSOLE" -ge "7" ] ; then
chvt $FGCONSOLE
else
chvt 7
chvt $FGCONSOLE
fi

If it still doesn't work try to add
Option "ForceEnablePipeA" "true"
to the <tt>Device</tt> section in your {{path|/etc/X11/xorg.conf}}.

===Solution for ThinkPads with ATI graphic (and possibly other) chips and FreeBSD===

The FreeBSD acpi(4) manpage mentions a tunable parameter, "hw.acpi.reset_video":

hw.acpi.reset_video
Reset the video adapter from real mode during the resume path.
Some systems need this help, others have display problems if it
is enabled. Default is 0 (disabled).

This tunable can be set by adding the following line to your FreeBSD machine's /boot/loader.conf file:

hw.acpi.reset_video="1"

And rebooting your machine. Hopefully, the next time you resume from a suspend, you'll see your video again. This solution doesn't appear to be specific to ATI hardware in any way, so I presume it would be helpful for video chipsets other than ATI, as well.

If this entry doesn't help you, you might consider searching in the [http://lists.freebsd.org/pipermail/freebsd-mobile/ FreeBSD-Mobile email-list archive] for more insight.

{{footnotes|
#If you have this problem with R50e and the above solution doesn't work, try switching to console first. An example sleep script can be found [[How to configure acpid|here]].
}}

===Solution using s2ram for Intel 915/945GM===

Just using the "s2ram -f -p" command from the uswsusp package will work from within X, at least on a {{Z61e}}. On {{X60s}} it is enough to issue the "s2ram" command and it works. On {{X61}} "s2ram -f -a 1" can work properly. Best idea seems to be to put this into the corresponding acpi script:

% cat /etc/acpi/sleep.sh
#!/bin/sh
test -f /usr/share/acpi-support/power-funcs || exit 0
test -f /usr/sbin/s2ram || exit 0
rmmod usb_storage
rmmod uhci_hcd
rmmod ehci_hcd
/usr/sbin/s2ram -f -a 1 -m
modprobe uhci_hcd
modprobe ehci_hcd
modprobe usb_storage

Source: [http://d.hatena.ne.jp/conceal-rs/20080309/1205083315 http://d.hatena.ne.jp/conceal-rs/20080309/1205083315]
Works on my X61.

T400S (intel mobile 4 integrated graphics) and kernel lenny-2.6.30-amd64: seems good so far (around 5 suspends without problems).

===Solution using DOUBLE_CONSOLE_SWITCH===

By setting the following in {{path|/etc/default/acpi-support}} the display comes back on {{X61s}} using Intel chipset:

DOUBLE_CONSOLE_SWITCH=true

Fedora 8 doesn't have DOUBLE_CONSOLE_SWITCH, but it works when one does: First, add option "VBERestore" "true" to /etc/X11/xorg.conf

Section "Device"
Identifier "Videocard0"
Driver "intel"
Option "VBERestore" "true"
EndSection

Then suspends with

pm-suspend --quirk-vbemode-restore --quirk-s3-bios

===Solution for nvidia-drivers-180* series===

The proprietary NVidia drivers of the 180 series introduce several problems with suspend to ram:

* Situation 1: Suspend from console, '''no''' X-Server running:<br/>
You might need to use vbetool to save and restore the vbestate.
When using hibernate-script, this can be done by setting the following config variables:
EnableVbetool yes
RestoreVbeStateFrom /var/lib/vbetool/vbestate
VbetoolPost yes

You may need to run <code>mkdir -p /var/lib/vbetool && vbetool vbestate save > /var/lib/vbetool/vbestate</code> first.

On newer distributions, you might need to '''not''' use vbetool. On a Ubuntu Hardy with Linux 2.6.24, and probably on other Debian-based distributions, edit '/etc/default/acpi-support' and set 'SAVE_VBE_STATE=false'.

* Situation 2: Suspend from running X-Server:<br/>
You '''cannot''' use vbetool or any other quirks, since it seems to confuse the nvidia X driver. That means you should enter S3 simply by doing <code>echo mem > /sys/power/state</code>.

If you have your hotkeys handled by acpid, you might differentiate those two cases by checking for a running X process in your hotkey handler (i.e. <code>/etc/acpid/default.sh</code>):
pgrep -x X > /dev/null \ # checks for running process with name "X"
&& echo mem > /sys/power/state # if found, do plain S3 suspend
|| hibernate-ram # otherwise, run quirked script

Furthermore, it seems to be a good idea to use the 180 series with a 2.6.28* kernel.

It has been reported that acpi_sleep=S3_bios should be used instead of acpi_sleep=S3_mode
as a boot option.

See, http://www.nvnews.net/vbulletin/showthread.php?t=123303&highlight=suspend&page=6

It might also help to put <code>blacklist intel_agp </code>
in <code>/etc/modprobe.d/blacklist

Finally, it seems to depend on precise model nr.
See
https://bugs.launchpad.net/ubuntu/+bug/235284
for a discussion and patch.

=== Quirk workaround for T410s ===
The vbe post quirk in pm-utils works on a T410s 29123KC.

On Debian sid pm-utils script is hacked to apply '--quirk-vbe-post' when kms is in place.