Difference between revisions of "Talk:Problem with display remaining black after resume"

From ThinkWiki
Jump to: navigation, search
m (X41 with an Intel 915GM Integrated Graphics Device)
(Windows too)
 
(21 intermediate revisions by 13 users not shown)
Line 1: Line 1:
 +
== 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 ==
 
== 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
 
My T43 (1871-FYG) with Intel 915GM is also affected by the problem and the 'ATI' sollution with
Line 46: Line 54:
  
 
Kapil kapil at imsc dot res dot in
 
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 ==
 
== X40 with an Intel 855GM Integrated Graphics Device ==
Line 62: Line 78:
 
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}}.
 
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 ==
 
== X41 with an Intel 915GM Integrated Graphics Device ==
Line 69: Line 103:
 
: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)
 
: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.
+
:(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) ==
 
== Z60t with an Intel 915GM Integrated Graphics Device (PCI Express) ==
Line 128: Line 166:
  
 
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.
 
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.

Latest revision as of 23:55, 20 November 2010

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.

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.

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 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 X31 talk page. TheAnarcat 18:50, 14 July 2007 (UTC)

X40 with an Intel 855GM Integrated Graphics Device

I used the 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 acpi_sleep=s3_bios boot parameter alone did not fix things, and neither did saving and restoring the information from /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 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. --A76b034a 21:29, 30 September 2009 (UTC)

X41 with an Intel 915GM Integrated Graphics Device

It works with the 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. BrianTung 19:52, 30 April 2006 (CEST) (fixed a little)
(gsaito): I used the 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. 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. Sirmoloch 11:49, 4 July 2006 (CEST)

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

It works with the 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 # clear to the script before # chvt 'ing back to VT7 after wakeup. If I didn't, I would end up with a 99% black corrupted screen in X. 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? 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! 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

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.