Difference between revisions of "Problem with display remaining black after resume"
(→Solution for ThinkPads with ATI graphic chips (or Intel 915GM)) |
m (grammar nit in ATI/915GM section) |
||
Line 39: | Line 39: | ||
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. | ||
− | In {{Fedora}}, it may be necessary with Intel chips to edit the {{path|resume_video()}} function in {{path|/etc/pm/functions-intel}}, by commenting out the VBE post and restore. Furthermore, you may experience a problem where the laptop, after it wakes up, goes back to sleep whenever the AC adapter is disconnected. When this happens, it is caused by a bug in the HAL daemon that incorrectly reports the lid as closed ({{path|lshal}} | + | In {{Fedora}}, it may be necessary with Intel chips to edit the {{path|resume_video()}} function in {{path|/etc/pm/functions-intel}}, by commenting out the VBE post and restore. Furthermore, you may experience a problem where the laptop, after it wakes up, goes back to sleep whenever the AC adapter is disconnected. When this happens, it is caused by a bug in the HAL daemon that incorrectly reports the lid as closed ({{path|lshal}} returns {{bootparm|button.state.value|true}}, among other things). The simplest way to resolve this is to add a line to the sleep script to restart the HAL daemon: |
# restart the HAL daemon | # restart the HAL daemon |
Revision as of 01:09, 7 May 2006
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.
Affected Models
- ThinkPad T41p, T42, T42p, T43p
- Thinkpad T23
- ThinkPad X21, X30, X31, X40, X41
- ThinkPad R31, R50e1, R50p, R51 (with BIOS 1.11), R52
- ThinkPad A30p
- ThinkPad 390X (doesn't wake up; LCD backlight on, harddrive light remains on)
- ThinkPad Z60t
Affected Operating Systems
- Linux (it's a kernel issue)
Solutions
Solution for ThinkPads with 1400x1050 internal LCD and Intel 915GM
Solution for ThinkPads with ATI graphic chips (or Intel 915GM)
One solution may be to provide the acpi_sleep=s3_bios
kernel parameter in your kernel parameter line.
For grub this can 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 can 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 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.
In Fedora, it may be necessary with Intel chips to edit the resume_video() function in /etc/pm/functions-intel, by commenting out the VBE post and restore. Furthermore, you may experience a problem where the laptop, after it wakes up, goes back to sleep whenever the AC adapter is disconnected. When this happens, it is caused by a bug in the HAL daemon that incorrectly reports the lid as closed (lshal returns button.state.value=true
, among other things). The simplest way to resolve this is to add a line to the sleep script to restart the HAL daemon:
# restart the HAL daemon service haldaemon restart
If you do this, it will unfortunately crash gnome-power-manager, if you use that, though it can be restarted manually.
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).
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.
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
Solution for ThinkPads with Intel I830 Chipset
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.
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
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.