Difference between revisions of "Problem with display remaining black after resume"
(→Solution for ThinkPads with ATI graphic chips (or Intel 915GM)) |
(→Affected Models) |
||
(72 intermediate revisions by 46 users not shown) | |||
Line 4: | Line 4: | ||
==Affected Models== | ==Affected Models== | ||
− | *ThinkPad {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}} | + | *ThinkPad {{T41p}}, {{T42}}, {{T42p}}, {{T43}}, {{T43p}}, {{T60}}, {{T60p}}, {{T61}}, {{T61p}} {{T410s}} |
*Thinkpad {{T23}} | *Thinkpad {{T23}} | ||
*ThinkPad {{X21}}, {{X30}}, {{X31}}, {{X40}}, {{X41}} | *ThinkPad {{X21}}, {{X30}}, {{X31}}, {{X40}}, {{X41}} | ||
− | *ThinkPad {{R31}}, {{R50e}}{{footnote|1}}, {{R50p}}, {{R51}} (with BIOS 1.11), {{R52}} | + | *ThinkPad {{R31}}, {{R50e}}{{footnote|1}}, {{R50p}}, {{R51}} (with BIOS 1.11), {{R52}}, {{R60}}, {{R61}} |
*ThinkPad {{A30p}} | *ThinkPad {{A30p}} | ||
*ThinkPad {{390X}} (doesn't wake up; LCD backlight on, harddrive light remains on) | *ThinkPad {{390X}} (doesn't wake up; LCD backlight on, harddrive light remains on) | ||
− | *ThinkPad {{Z60t}}, {{Z60m}} | + | *ThinkPad {{Z60t}}, {{Z60m}}, {{Z61m}}, {{Z61e}} |
− | *ThinkPad {{X60s}} | + | *ThinkPad {{X40}}, {{X60s}}, {{X60}}, {{X61}}, {{X61s}}, {{X200}}, {{X200s}}, {{X201s}} |
+ | *Thinkpad {{X1_Extreme_G2}} | ||
==Affected Operating Systems== | ==Affected Operating Systems== | ||
*Linux (it's a kernel issue) | *Linux (it's a kernel issue) | ||
+ | *FreeBSD (6.x at least) | ||
+ | *Windows XP | ||
==Solutions== | ==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. Upgrading the BIOS fixes the issue for R61i. | ||
+ | |||
+ | 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 === | ===Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM === | ||
see [[1400x1050 on Intel 915GM]]. | see [[1400x1050 on Intel 915GM]]. | ||
− | ===Solution for ThinkPads with ATI graphic chips | + | ===Solution for ThinkPads with ATI graphic chips and Intel 915/945GM === |
+ | |||
+ | Affected models include {{X41}}, {{X60s}}, {{X200s}}, {{R60}}, {{T60}}, and {{Z61t}}. | ||
+ | |||
+ | This soluton also applies to T42 with Intel 855 and ATI 9600 M10. | ||
+ | |||
+ | {{WARN|The use of {{bootparm|acpi_sleep|s3_bios}} can cause subtle and pervasive system corruption in kernels after 2.6.32 or so. Its use should be avoided; all other alternatives should be considered first. (Details: {{bootparm|acpi_sleep|s3_bios}} causes the kernel to call the BIOS POST code during resume-from-RAM. The kernel's resume path does not provide the execution environment expected by POST code, resulting in nasty side-effects.)}} | ||
+ | |||
One solution may be to provide the {{bootparm|acpi_sleep|s3_bios}} kernel parameter in your kernel parameter line. | One solution may be to provide the {{bootparm|acpi_sleep|s3_bios}} kernel parameter in your kernel parameter line. | ||
Line 40: | Line 98: | ||
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 [[: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. | + | 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. 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]. | + | 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.}} | {{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}}). | 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=== | ===Solution for ThinkPads with Intel Extreme Graphics 2=== | ||
Line 57: | Line 155: | ||
*Before suspending, change to a console and safe the video state with {{cmdroot|cat /proc/bus/pci/00/02.0 > /tmp/video_state}}. | *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. | *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 | *For a R50e the only thing needed to make suspend to ram work in Ubuntu 6.06 is adding | ||
Option "VBERestore" "yes" | Option "VBERestore" "yes" | ||
Line 93: | Line 197: | ||
# clean up behind us | # clean up behind us | ||
rm /tmp/video_state | 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=== | ===Solution for ThinkPads with Intel I830 Chipset=== | ||
The following solution worked for me on an X30 with I830M chipset with kernel >= 2.6.16. | The following solution worked for me on an X30 with I830M chipset with kernel >= 2.6.16. | ||
− | *this works with vesafb and also with intelfb frambuffer support. | + | |
+ | 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. | The following example {{path|/etc/acpi/actions/sleep.sh}} script shows how to integrate the according lines. | ||
Line 117: | Line 233: | ||
chvt $FGCONSOLE | chvt $FGCONSOLE | ||
fi | 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. | ||
Line 122: | Line 259: | ||
#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]]. | #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. |
Latest revision as of 08:33, 23 September 2020
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 CtrlAltDel.
Contents
- 1 Affected Models
- 2 Affected Operating Systems
- 3 Solutions
- 3.1 Quick workaround for R61i, T23, maybe others
- 3.2 Quick Workaround for R61 (at least 8918-5QG) using NVidia
- 3.3 Quick Workaround for T61 (at least 7662-CTO) using NVidia Quadro NVS 140
- 3.4 Pseudo-solution for R61
- 3.5 Solution for ThinkPad Z60t
- 3.6 Semi-Solution for ThinkPad X60 with damaged system after s2ram usage
- 3.7 Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM
- 3.8 Solution for ThinkPads with ATI graphic chips and Intel 915/945GM
- 3.9 Solution for ThinkPads with Intel Extreme Graphics 2
- 3.10 Solution for ThinkPads with Intel I830 Chipset
- 3.11 Solution for ThinkPads with ATI graphic (and possibly other) chips and FreeBSD
- 3.12 Solution using s2ram for Intel 915/945GM
- 3.13 Solution using DOUBLE_CONSOLE_SWITCH
- 3.14 Solution for nvidia-drivers-180* series
- 3.15 Quirk workaround for T410s
Affected Models
- ThinkPad T41p, T42, T42p, T43, T43p, T60, T60p, T61, T61p T410s
- Thinkpad T23
- ThinkPad X21, X30, X31, X40, X41
- ThinkPad R31, R50e1, 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
- Thinkpad X1 Extreme G2
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. Upgrading the BIOS fixes the issue for R61i.
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 /etc/pm/config.d/config
and put there one line DISPLAY_QUIRK_S3_BIOS="true"
, 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
Solution for ThinkPads with ATI graphic chips and Intel 915/945GM
Affected models include X41, X60s, X200s, R60, T60, and Z61t.
This soluton also applies to T42 with Intel 855 and ATI 9600 M10.
acpi_sleep=s3_bios
can cause subtle and pervasive system corruption in kernels after 2.6.32 or so. Its use should be avoided; all other alternatives should be considered first. (Details: acpi_sleep=s3_bios
causes the kernel to call the BIOS POST code during resume-from-RAM. The kernel's resume path does not provide the execution environment expected by POST code, resulting in nasty side-effects.)One solution may be to provide the 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 sleep.sh script in the Extreme Graphics 2 section below, but note the following comments:
In 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 SUSPEND2RAM_FORCE="yes"
and SUSPEND2RAM_ACPI_SLEEP="3"
in /etc/powersave/sleep.
In Ubuntu or Kubuntu, it may be necessary to modify /etc/default/acpi-support. In that file, make sure that ACPI_SLEEP is uncommented and set to true. With ATI chips, also make sure that 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 resume_video() function in /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 here.
Another solution is to use vbetool. If you are using Debian with the hibernate package, uncomment "EnableVbetool yes" in /etc/hibernate/hibernate.conf (or /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
S2RAM_QUIRKS_SOURCE="s2ram"
to file /etc/pm/config.d/config - Create an executable script /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 (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
The following solution should work on 865G, 865GV, 855GM, 855GME, 852GME chipsets.
- First of all, do not use the
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
# cat /proc/bus/pci/00/02.0 > /tmp/video_state
. - On resume, restore the video state with
# 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 Device section in your /etc/X11/xorg.conf, and the example script below.
The following example /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 R51 (2887-32G) I just (as none of the other tricks above) had to add fb=false
to the kernel line in /etc/grub/menu.lst and edit /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 /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 Device section in your /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 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 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 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 /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:
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 mkdir -p /var/lib/vbetool && vbetool vbestate save > /var/lib/vbetool/vbestate
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:
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 echo mem > /sys/power/state
.
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. /etc/acpid/default.sh
):
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 blacklist intel_agp
in /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.