vbetool breaks resume on R50e

[Reinhard Tartler]

My machine: https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadR50e

Suspending results in a suspended machine with the blinking moon symbol first, and the LED light if the machine has suspended. No problem here.

On resume, the moon keeps on blinking, but never stops. There is some HDD activity (a very short flackering every few seconds), but nothing more. Switching VTs doesn't work. I can however use the MagicSysRQ reboot the machine.

disabling vbetool by setting POST_VIDEO=false in /etc/default/acpi-support AND using the VBERestore option of the i810 xorg driver makes the machine suspend/resume as normal.

This bug was filed on Matthew's request in bug #18113

[Matthew Garrett (mjg59)]

Can you attach the output of the dmidecode command?

[Reinhard Tartler (siretart)]

As requested, the output of the command 'sudo dmidecode'

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

I can confirm this.

[Reinhard Tartler (siretart)]

dieguito, since this bug is hardware specific, could you please attach the output of 'sudo dmidecode' and 'lspci' to this bug? We need to know on what machines this happens.

[Paul Sladen (sladen)]

The Green moon flashing and SysRq working means that a significant portion of the userspace is back and it is likely that the only remaining problem is the video drivers not restoring state.

As requested by siretart, can you attach the output of:

  lspci -n

so that we can work out what video card you have (it'll likely be an i810 of some sort as this is a 'cheap' machine (which is what the 'e' after 'R50' indicates).

Currently we have the following whitelist:

        # R50e
        1834*|1842*|2670*)
                ACPI_SLEEP=true;
                SAVE_VIDEO_PCI_STATE=true;
                SAVE_VBE_STATE=false;
        ;;

in '/usr/share/acpi-support/IBM.config', which matches your model number of '18348RG'. Can you try altering some of those settings and let us know if any particular combination of them make the suspend work?

Also, what happens if you use 'Ctrl-Alt-BackSpace' to kill the X server, or 'ssh' into the machine remotely?

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

This is what dmidecode gives on my 1834-5US R50e

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

This is lspci -n on my R50e

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

I must add that this worked great and without problems in 5.10

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

Setting experimental=0 in modprobe.d/ibm_acpi.modprobe doesn't help.

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

Is more info needed?.

[Paul Sladen (sladen)]

Can you do:

  SysRq-s SysRq-u SysRq-b (Sync, Unmount, reBoot)

and then see if you can find the relavant snippet from:

  /var/log/messages

after reboot (make a note of the timestamps). Did you have any luck with SSH'ing into the machine and checking what state it is?

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

This is what I get.
You might notice that Xorg-air line, but I really don't think it's related to the problems since they were there before.

[Paul Sladen (sladen)]

Mmm, 'xorg-air' is what crashed; what happens if you don't start this and just use the plain i810 driver alone? The back trace for the i915 kernel module is:

Process Xorg-air (pid: 3865, threadinfo=cdf10000 task=cd975560)
Call Trace:
 i915_irq_emit+0xa8/0x110 [i915]
 i915_irq_emit+0x0/0x110 [i915]
 drm_ioctl+0xa8/0x217 [drm]
 do_ioctl+0x93/0xa0
 vfs_ioctl+0x6b/0x230
 sys_ioctl+0x88/0xa0
 sysenter_past_esp+0x54/0x75

which is DRM related.

[Angelo Lisco (angystardust-gmail)]

Please, if you're using Xorg-air, switch back to Xorg...there's a known bug in Aiglx when you suspend-to-ram or hibernate...i can reproduce it here with my intel 855gm...it's not a dapper goal to support Aiglx! Let's talk only about Xorg bugs, please.

[Paul Sladen (sladen)]

Yup, this is bling; perhaps something we can look at for the dapper+1 release.

Can you check that just the plain i810 driver *is* functioning as expected.

[Reinhard Tartler (siretart)]

I don't have xorg-air installed, and my crash is not DRM related

[Reinhard Tartler (siretart)]

It is not the DRM that is crashing for me, maybe it's the kernel which gets confused with interrupt routing?

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

This log if from when I didn't have xorg-air and suspend didn't work.
As Reinhard says, this seems to be unrelated to DRM. In my personal experience this has worked great until 3 or 4 weeks ago (always using dapper).
First I had some problems getting back from suspend and now I just can't get back.

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

This is a more recent try (using only standar stuff).
I clicked the Log out -> Sleep button.

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

Using the latest kernel in dapper (-23 marked as final kernel) I got this funky vbetool output in /var/log/messages:

May 20 06:50:05 milkyway kernel: [4294834.649000] Pid: 4658, comm: vbetool
May 20 06:50:05 milkyway kernel: [4294834.649000] EIP: 0060:[system_call+0/50] CPU: 0
May 20 06:50:05 milkyway kernel: [4294834.649000] EIP is at system_call+0x0/0x32
May 20 06:50:05 milkyway kernel: [4294834.649000] EFLAGS: 00003206 Not tainted (2.6.15-23-686)
May 20 06:50:05 milkyway kernel: [4294834.649000] EAX: 00000071 EBX: 0804b18c ECX: 000c4a5a EDX: 30001800
May 20 06:50:05 milkyway kernel: [4294834.649000] ESI: 00004a5a EDI: bfd01d3e EBP: bfd01f48 DS: 007b ES: 007b
May 20 06:50:05 milkyway kernel: [4294834.649000] CR0: 8005003b CR2: 0805b420 CR3: 0ebe5000 CR4: 00000690
May 20 06:50:05 milkyway kernel: [4294834.932000]

And a lot of similar ones.

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

I dont want to be a PITA but, any more info needed?

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

It took me a while, but after some debugging I finally worked this out.

As I said I'm using a Thinkpad R50e (1834-5US). After resuming the system everything looked frozen.
Well I had access to a second PC today and SSH'd into my laptop. It worked fine so the problem was that the video wasn't responding (I was getting the screen back but with a frozen image).
I played with the proposed solutions in the previous comments but without success.

I googled for some obvious keywords and I found this great wiki:
http://www.thinkwiki.org/wiki/Problem_with_display_remaining_black_after_resume#Solution_for_ThinkPads_with_Intel_Extreme_Graphics_2

The I applied the proposed script (replacing my sleep.sh) and it worked GREAT!.
Now it's even faster to suspend and resume than ever.

Please people, try this out so we can have happy ubuntu users even if they use one of our models.

PD: I tried the suspend with gnome-power-manager and the command line (sh sleep.sh).

[Yannick (splitsch)]

Hello,
Here is my sleep.sh file
#####################
#!/bin/bash

/bin/sync

/sbin/rmmod uhci-hcd
/sbin/rmmod ehci-hcd

/usr/bin/chvt 1

cat /proc/bus/pci/00/02.0 > /var/cache/video.config

echo -n mem > /sys/power/state

cat /var/cache/video.config > /proc/bus/pci/00/02.0

rm -rf /var/cache/video.config

/usr/bin/chvt 7

/sbin/modprobe uhci-hcd
/sbin/modprobe ehci-hcd
###########################

I don't know what it does, but it works well! With or without poweradaptater plugged-in.
I'm using Kubuntu dapper full updated.
If someone could explain ti me what this script does, and could make it better :)
Thanks!

ps: I must add that all the solution proposed didn't work.

[Vladimír Lapáček (vil)]

Unfortunatelly, I experience this bug too on my R50e 1834S5G with Dapper. I succeded partially solving it with commenting out the POST_VIDEO=true option in /etc/default/acpi-support. Now it resumes normally in some cases. However, sometimes it does not restore to the X session. Only a cursor on black screen appears after a while. I suppose that this means that the X server crashes on resume and GDM tries to restart it. Does anyone experience such behaviour?

[Vladimír Lapáček (vil)]

This is dmidecode for my Thinkpad R50e 1834S5G.

[Vladimír Lapáček (vil)]

And here is log captured when resuming my laptop. You can see the dying gdm there.

[Paul Sladen (sladen)]

The file you want to grab is:

  /var/log/Xorg.0.log

from after X died; this is likely bug #28326.

[Vladimír Lapáček (vil)]

Yes, you are right. It seems very much like the Bug #28326. That one is marked as Fix Released. I am using the latest Dapper. Should it be fixed here? Thanks.

[Vladimír Lapáček (vil)]

Well, I finally found a solution at least for me. As I wrote earlier, I got rid of the "Green moon constantly blinking" (name of this bug) by commenting out the POST_VIDEO=true in the /etc/defaults/acpi-support file. However, after that I got random crashes of X server. Searching through similar reports I found that setting the

Option "VBERestore" "true"

in the /etc/X11/xorg.conf make me happy :) and wakes my laptop nicely.

Again, I am using TP R50e 1834-S5G with Intel Corporation 82852/855GM Integrated Graphics Device (rev 02).

[Matthew Garrett (mjg59)]

Given the vbe saving/restoring performed with vbetool, the X option
should be entirely unnecessary. Possibly this needs to be done after PCI
state restoration - could you try removing the option from xorg.conf,
and then editing /etc/acpi/resume.d/17-video-restore.sh and move the
"Restore video PCI state" block above the "Attempt to restore some video
card state" block?

--
Matthew Garrett | <email address hidden>

[Vladimír Lapáček (vil)]

I just tried it. Unfortunatelly, it gives me corrupted display on resume -
one of the symptoms I got without VBERestore option. So I revert to it,at
least for now. If you would have any other hints, feel free to tell me what
to do.

On 6/11/06, Matthew Garrett <email address hidden> wrote:
>
> Given the vbe saving/restoring performed with vbetool, the X option
> should be entirely unnecessary. Possibly this needs to be done after PCI
> state restoration - could you try removing the option from xorg.conf,
> and then editing /etc/acpi/resume.d/17-video-restore.sh and move the
> "Restore video PCI state" block above the "Attempt to restore some video
> card state" block?
>
> --
> Matthew Garrett | <email address hidden>
>
> --
> R50e Resume requires "VBERestore" "true" in xorg.conf
> https://launchpad.net/bugs/40621
>

[Reinhard Tartler (siretart)]

I tried both suggestions (Option "VBERestore" "true") and editing /etc/acpi/resume.d/17-video-restore.sh. But neither makes my R50e resume from suspend. :(

[Vladimír Lapáček (vil)]

Please, try commenting oun the POST_VIDEO=true option (so that it looks like
#POST_VIDEO=true) in the /etc/defaults/acpi-support file. This helped on
mine.

On 6/25/06, Reinhard Tartler <email address hidden> wrote:
>
> I tried both suggestions (Option "VBERestore" "true") and editing
> /etc/acpi/resume.d/17-video-restore.sh. But neither makes my R50e resume
> from suspend. :(
>
> --
> R50e Resume requires "VBERestore" "true" in xorg.conf
> https://launchpad.net/bugs/40621
>

[Reinhard Tartler (siretart)]

Ok, I tried a bit further, and it seems, that the order in /etc/acpi/resume.d/17-video-restore.sh doesn't matter, neither does the option VBERestore in /etc/X11/xorg.conf. For me, the trick was to uncomment POST_VIDEO=true.

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

This script fixes the problem on my R50e :).

[Reinhard Tartler (siretart)]

my previous comment was unclear (in fact, mistyped). POST_VIDEO=true must be commented out. then, suspend works for me (both dapper and current edgy)

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

Correcting my previous comment, the script corrupts my video in Edgy.

I made the following changes to make suspend and hibernate work in Edgy:
/etc/defaults/acpi-support:
POST_VIDEO = false

/etc/X11/xorg.conf:
Section "Device"
   Identifier "Intel Corporation 82852/855GM Integrated Graphics Device"
   Driver "i810"
   BusID "PCI:0:2:0"
   Option "VBERestore" "true"
EndSection

[ave (ta)]

Here's my take on the R50e suspend/resume deal.

Ingredients:
 - up to date edgy as of 07-10-2006
 - acpi-support 0.89
 - kernel 2.6.17-10-386

So I have stock setup regarding kernel and acpi-tools.

To make things work, I only had to add one line in /usr/share/acpi/IBM.config as follows (the POST_VIDEO one):

        # R50e
        1834*|1842*|2670*)
                ACPI_SLEEP=true;
                SAVE_VIDEO_PCI_STATE=true;
                SAVE_VBE_STATE=false;
                POST_VIDEO=false;
        ;;

During all this experimentation I can't be 100% sure it really is this simple even tho it appears to be so.

Could someone please confirm?

[ave (ta)]

Oops. Well it turns out, just like the topic says, graphics get corrupted unless I have Option "VBERestore" "true" in Xorg conf.

So with these two changes and stock config all oughta be well.

[John S (jcspray)]

+1:
On my R50e with Edgy, I just need Option "VBERestore" "true" in xorg.conf and POST_VIDEO=false in /usr/share/acpi-support/IBM.config.

Then suspend to RAM works perfectly. Can we get this working out of the box before Edgy's finalised?

[Reinhard Tartler (siretart)]

Summary: we found a case, where vbetool breaks resuming the machine, whereas the VBERestore code in the xorg i810 driver manages to restore the inital text mode using the option "VBERestore" true.

I think it is too late for edgy to consider this workaround. I think vbetool should be fixed to work on an R50e.

[Axel Bojer (axelb)]

See also:
https://launchpad.net/ubuntu/+bug/47508

I added some relevant information there, perhaps it will also be important for this bug.

[Thomas Jacobson (thomas-tcjnet)]

Folks,

Here is a possible work-around to the Thinkpad blank/garbage screen on resume problem (vbetool "post" reset) that seems to work for me, and may suggest where to look for the actual bug.

Thinkpad A31p running a clean Dapper upgraded to Edgy after spending a day trying all of the solutions discussed above and in other threads, I found that adding a "sleep 5" before the "vbetool post" in /etc/acpi/resume.d/15-video-post.sh and with POST_VIDEO=true in /etc/default/acpi-support seems to result in reliable resume (I tried 1 and 3 seconds but it was not enough on my 1.7Ghz Thinkpad A31p with ATI Radeon RV200 LX [Mobility FireGL 7800 M7])

Here is my /etc/acpi/resume.d/15-video-post.sh:

#!/bin/sh

# Post the video card
if [ x$POST_VIDEO = xtrue ]; then
# Temporary kluge: Adding a "sleep 5" seems to eliminate the blank/garbage screen after POST_VIDEO
# (i.e. the ATI controller must be slow or busy after waking up, and perhaps is not ready for the reset from vbetool somehow)
  sleep 5
  vbetool post
fi

Other data/discussion: No apm stuff running, only stock acpi. You seem to have to vbetool post the video controller to reset it no matter what (POST_VIDEO=true) otherwise you get a blank screen or garbage and can not enter your password for the resume. The sleep 5 makes it work. The kluge is reproducible, I can turn POST_VIDEO true and false with consistent results.

Thomas.

[Mark Edgington (edgimar)]

Just wanted to note that the "sleep 5" fix isn't specific to the R50e. It also works for the Dell Inspiron 6400 (a.k.a E1505). There was only one other needed change -- according to bug #23497 comments 5 and 6 -- adding /etc/acpi/suspend.d/20-i8042-input.sh and /etc/acpi/resume.d/40-i8042-input.sh , to prevent the mouse and keyboard from locking up after resume.

[GioSico (john-giosico)]

I too have the 'on wake' from suspend black screen of death with a small box of vertical wavy lines.

I am running Feisty on a HP Pavillion dv6000.

Moving away the btn files and then sim linking them as follows fixed my sleep problem but not my hibernate problem ...

ln -s /etc/acpi/sleep.sh /etc/acpi/sleepbtn.sh
ln -s /etc/acpi/hibernate.sh /etc/acpi/hibernatebtn.sh

Also posted in bug https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/47508

[GioSico (john-giosico)]

Ok I have tried everything described above and suspend still does not work ...

However setting /etc/acpi/resume.d/15-video-post.sh: as described above changed from have a black screen with a small square of squiggly line to just a black screen.

See my attachments below ...

If anyone has any ideas of commands I could try and run your help would be much appreciated ...

[GioSico (john-giosico)]

Attaching lspc -n output

[Yannick (splitsch)]

Hello!
The bug still exist on a fresh installed Ubuntu Gutsy beta, and on an up-to-date Gutsy.

Bye

[Mahdi (mahdi-hates-spam)]

Works fine with latest gutsy (2.6.22-14) and VBE_POST=false (no xorg option) on a Toshiba A205-S4797.

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

The xorg option is now ignored, that produce corrupted graphics always.

[Anton (feenstra)]

Mahdi, where would that VBE_POST option be?
Are you perhaps referring to POST_VIDEO=true in acpi-support?

Google on VBE_POST=false leads exclusively to this bug, with VBE_POST=true I find some hits on 'power_management.quirk', but they don't go into explanations there.
Is that what you meant? If so, where/how to set it?

[Yannick (splitsch)]

Hello!
I just finished to install a fresh Kubuntu gutsy, and it doesn't work. After all the advice here and all the changes, it still doesn't work :(

Do you have any idea? On ubuntu, I managed somehow to make it work, but I don't remember how...

Thanks

Yannick

[Anton (feenstra)]

Yannick wrote:
> Hello!
> I just finished to install a fresh Kubuntu gutsy, and it doesn't work. After all the advice here and all the changes, it still doesn't work :(
>
> Do you have any idea? On ubuntu, I managed somehow to make it work, but
> I don't remember how...

For me it works, mostly, using:

# Should we save and restore state using the VESA BIOS Extensions?
SAVE_VBE_STATE=false

# Should we attempt to warm-boot the video hardware on resume?
POST_VIDEO=false

# Save and restore video state?
SAVE_VIDEO_PCI_STATE=false

# Uncomment the next line to switch away from X and back again after
# This is needed for some hardware, but should be unnecessary on most.
DOUBLE_CONSOLE_SWITCH=true

I'm running an Intel 945GM. I'm not sure about the double switch, it
seems to be necessary sometimes, but not often.

--
Groetjes,

Anton
  _____________ _______________________________________________________
| | |
| _ _ ___,| K. Anton Feenstra |
| / \ / \'| | | IBIVU/Bioinformatics - Free University Amsterdam |
|( | )| | | De Boelelaan 1083A - 1081 HV Amsterdam - Netherlands |
| \_/ \_/ | | | Tel [phone] - Fax [phone] - Room P136 |
| | <email address hidden> - www.few.vu.nl/~feenstra/ |
| | "A Lady Shaves Her Legs" (C. Meijering) |
|_____________|_______________________________________________________|

[Yannick (splitsch)]

Hello!
I made those change on a fresh Kubuntu gutsy, and it does'nt do anything: when the screen goes on, the image is garbage: block spot behind the menu, the writing in firefox don't show up, etc...
Any other idea?

Thanks :)

[Anton (feenstra)]

Yannick wrote:
> Hello!
> I made those change on a fresh Kubuntu gutsy, and it does'nt do anything: when the screen goes on, the image is garbage: block spot behind the menu, the writing in firefox don't show up, etc...
> Any other idea?

I've attached my acpi-support file, maybe there are some other
differences that may be relevant?

Otherwise, I'm not sure. I myself still experience the occasional lockup
at resume. It happens more often after suspend, and less after
hibernate, but I have not been able to find a definite pattern there...

As an aside, network often fails to come up properly at resume as well
(with 'sudo killall NetworkManager && sudo Networkmanager' as an easy
but inappropriate workaround...). I don't suppose this is related, but
mention it just in case (please do redirect nm related stuff to the
appropriate bug/thread!).

--
Groetjes,

Anton
  _____________ _______________________________________________________
| | |
| _ _ ___,| K. Anton Feenstra |
| / \ / \'| | | IBIVU/Bioinformatics - Free University Amsterdam |
|( | )| | | De Boelelaan 1083A - 1081 HV Amsterdam - Netherlands |
| \_/ \_/ | | | Tel [phone] - Fax [phone] - Room P136 |
| | <email address hidden> - www.few.vu.nl/~feenstra/ |
| | "A Lady Shaves Her Legs" (C. Meijering) |
|_____________|_______________________________________________________|

# Comment the next line to disable ACPI suspend to RAM
ACPI_SLEEP=true

# Comment the next line to disable suspend to disk
ACPI_HIBERNATE=true

# Change the following to "standby" to use ACPI S1 sleep, rather than S3.
# This will save less power, but may work on more machines
ACPI_SLEEP_MODE=mem

# Add modules to this list to have them removed before suspend and reloaded
# on resume. An example would be MODULES="em8300 yenta_socket"
#
# Note that network cards and USB controllers will automatically be unloaded
# unless they're listed in MODULES_WHITELIST
MODULES="ipw3945"
# MODULES=""

# Add modules to this list to leave them in the kernel over suspend/resume
MODULES_WHITELIST=""

# Should we save and restore state using the VESA BIOS Extensions?
SAVE_VBE_STATE=false
# SAVE_VBE_STATE=true

# The file that we use to save the vbestate
VBESTATE=/var/lib/acpi-support/vbestate

# Should we attempt to warm-boot the video hardware on resume?
POST_VIDEO=false
#POST_VIDEO=true

# Save and restore video state?
SAVE_VIDEO_PCI_STATE=false
# SAVE_VIDEO_PCI_STATE=true

# Should we switch the screen off with DPMS on suspend?
USE_DPMS=true

# Use Radeontool to switch the screen off? Seems to be needed on some machines
# RADEON_LIGHT=true

# Uncomment the next line to switch away from X and back again after resume.
# This is needed for some hardware, but should be unnecessary on most.
DOUBLE_CONSOLE_SWITCH=true
# DOUBLE_CONSOLE_SWITCH=true

# Set the following to "platform" if you want to use ACPI to shut down
# your machine on hibernation
HIBERNATE_MODE=shutdown

# Comment this out to disable screen locking on resume
# LOCK_SCREEN=true

# Uncomment this ...

[Sebastian Urban (surban)]

I am not sure if this is exactly the same problem, but I had similar problems on R61.

I fixed the problem by adding a wait after resume. You can try my solution by putting the attached script into /etc/acpi/resume.d

My acpi-support uses the default settings, i.e.
POST_VIDEO=true
SAVE_VBE_STATE=true
SAVE_VIDEO_PCI_STATE=false

Hope this helps.

[Yannick (splitsch)]

Hello!
I tired everything here, and it still doesn't work...
All the "tricks" give me the same result: the screen display is messed up.
I'm Using Kubuntu, it might have something to do with the problem, since I managed to make suspend ork great on ubuntu gutsy (gnome). I don't remember how, but it was with one of the trick on this page.

Any other clue?

Thanks

[Yannick (splitsch)]

Hello!
I tried the combinaison FN+F4 on my thinkpad r50e, and it goes to speed as usual. (even faster, though!).
Then, I close the lid, nothing happen, and when I open the lid, it resume really fast and reaaly great!

I suppose there are 2 different script, one triggered by the lid closing/opening, and one for the key combianison...

Anyway, I now know how to make the computer suspend!

Great !

Yan

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

Got it working again, I tweaked /usr/share/acpi-defaults/IBM.config:

        # R50e
        1834*|1842*|2670*)
                ACPI_SLEEP=true;
                SAVE_VIDEO_PCI_STATE=true;
                ###### toggled this two vars from false -> true
                SAVE_VBE_STATE=true;
                POST_VIDEO=true;
        ;;

I have a 1834, so if no one complains and it's not an obvious break, can we separate 1834 to it's own case and set true for SAVE_VBE_STATE and POST_VIDEO there?. Note that changing /etc/defaults/acpi-support had no effects for me. IBM.config was always preferred when suspending.

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

Now on Ibex, it's broken again :). Hardy was fine with my last comment. Now it's broken again.

[Bryce Harrington (bryce)]

I can put the change in that you mentioned in comment #59; could you confirm that making that change on intrepid solves it? Your last comment is a bit ambiguous on whether the setting still works.

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

It broke for me this Friday after a reboot, let me try again today and confirm.

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

Bryce, my tip:

        # R50e
        1834*|1842*|2670*)
                ACPI_SLEEP=true;
                SAVE_VIDEO_PCI_STATE=true;
                ###### toggled this two vars from false -> true
                SAVE_VBE_STATE=true;
                POST_VIDEO=true;
        ;;

works perfect with kernel 2.6.24-19-generic, however in 2.6.27-3-generic, it's broken. This seems to be kernel's fault, the same Ibex system with the older kernel suspends without problems, while using the new kernel will result in broken graphics on resume.

Current status: broken with kernel 2.6.27-3, works with 2.6.24-19

[Launchpad Janitor (janitor)]

This bug was fixed in the package acpi-support - 0.111

---------------
acpi-support (0.111) intrepid; urgency=low

  * lib/IBM.config: Change VBE state and POST_VIDEO for 1834's
    (LP: #40621, #211285)
  * Incorporate a portion of the changes from Debian, as detailed below.
    Debian has been accumulating valuable fixes and structural changes for
    some years, but it will take some time to digest all of them.

  [ Bart Samwel ]
  * ac.d/90-hdparm.sh, battery.d/90-hdparm.sh, resume.d/90-hdparm.sh,
    start.d/90-hdparm.sh: Set hdparm power management to 254 for all hard
    drives. Ignore errors while detecting of APM is supported. Set
    hdparm -B 128 while on battery in 90-hdparm.sh. Head parking is useful
    on the road for shock protection. Still set hdparm -B 254 while on AC.
    (Closes: #448673, #452489, #453478, #458787, #481685)
  * Switch from #!/bin/bash to #!/bin/sh in a number of scripts, and
    cleanup bashisms throughout. Continues a change started with 0.93.
    (Closes: #407510, #485435, #453861)
  * Add checks for existance of key-constants and state-funcs throughout
    scripts to prevent erroneous failures when using eeepc-acpi-scripts.
    Use "test ... || ..." style over "[ ... ] || ..." just for consistency.
    (Closes: #469556)
  * Check if we can actually open event device in acpi_fakekey.c.
    (Closes: #410478)
  * Correctly detect keyboard event device in acpi_fakekey.c. Apparently
    the power key is in the range checked by acpi_fakekey. It's now
    changed it so that it assumes that any input device which has a key in
    the QWERTYUIOP range is "the" keyboard.
    (Closes: #433771)
  * Remove useless use of grep in asus-touchpad.sh.
  * Add HOTK key names in events/asus-* for additional keys.
  * Support Asus Eee PC volume up/down and mute keys in events/asus-eee-volume-*.
    (Closes: #459326)
  * Add rotatescreen.sh, asus-rotate script to support Asus R1F tablet
    screen rotation.
    (Closes: #450531)
  * Reinstate thinkpad_acpi.modprobe to fix "Many Thinkpad X60 keys stop
    working". This was dropped in 0.106 perhaps too hastily.
    (Closes: #481253)

  [ Raphael Hertzog ]
  * Add a new SKIP_INTERFACES variables in /etc/default/acpi-support and use
    it to define network interfaces that are not tied to hardware to avoid
    shutting them down during suspend, such as lo, qemu, and dummy.
  * Improved package description in control file, thanks to Cl?ment Stenac.
    (Closes: #383691)

  [ Loic Minier ]
  * Install new manpage for acpi_fakekey, thanks Nico Golde.
    (Closes: #383365)
  * Fix "APCI" instead of "ACPI" typo in IBM.config; thanks Joshua Kwan;
    (Closes: #389511)

 -- Bryce Harrington <email address hidden> Wed, 24 Sep 2008 08:43:42 -0700

[Yannick (splitsch)]

Hello !
I'm running an up-to-date intrepid ibex system, on a thinkpad r50e, with acpi-support 0.112 and kernel 2.6.27-4-generic.

I didn't make anyother change or special config, but it still doesn't work.
I goes to sleep, when I close the lid, but on wake up, the screen remains black.

[diegoe (diegoe-deactivatedaccount-deactivatedaccount)]

That's most probably your kernel, try with 2.6.24, it doesn't work with 2.6.27 for me, no matter what options I use.

[Thomas Jacobson (thomas-tcjnet)]

Errr.. I am not sure whats what any more on this vbetool thing, however,
what I can tell you is that Hardy current as of Oct 20, 2008 works great
on my A31p (system model ID is 2653H5U). I am running the ati radeon
driver (fglrx does not support the FireGL 7800 used in this Thinkpad),
and I run 1600x1200 on the laptops UXGA TFT and an external VGA monitor
plugged in at 1024x768 using Virtual 2624 1200 in xorg.conf to support
the dual display.

 /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-ibm.fdi

 <!-- X31, T30 , A31p-->
      <match key="system.hardware.product" prefix_outof="2366;2653">
        <merge key="power_management.quirk.dpms_suspend"
type="bool">true</merge>
        <merge key="power_management.quirk.vbemode_restore"
type="bool">true</merge>
        <merge key="power_management.quirk.radeon_off"
type="bool">true</merge>
        <merge key="power_management.quirk.vbe_post"
type="bool">true</merge>
      </match>

This seems to fix the backlight being on during suspend, and some
sprinkles of bits on the screen(s) after a resume when you move windows
around. It might be a good idea to split this up into separate 2366 and
2653, as I can not speak to these additional lines working on 2366 systems.

Also note, if the Thinkpad has had it's motherboard changed, a person
may need to run the IBM hardware diagnostic disk and enter the system
info... so that hal will find the necessary info (ie. 2653). So, people
should always check the BIOS to see that it is reporting the correct
system model ID number...

Hope this is helpful.
Thomas.

PS- Let me know if you want a lshal or whatever.

Bryce Harrington wrote:
> I can put the change in that you mentioned in comment #59; could you
> confirm that making that change on intrepid solves it? Your last
> comment is a bit ambiguous on whether the setting still works.
>
> ** Changed in: acpi-support (Ubuntu)
> Status: Confirmed => Triaged
>
>

[Thomas Jacobson (thomas-tcjnet)]

Oh darn! No sooner than I say the hal quirk fixes to
20-video-quirk-pm-ibm.fdi fixed things for my A31p then Mr. Murphy
strikes and I have a blank screen on a resume every once in a while...
(actually, random bit patterns, fairly fine grained or all black I think).

However, a small bit of data. Since I am now running in a dual screen
setup, my VGA attached 1024x768 screen was not affected...it resumed
just fine, and when I run vbetool post or restart X (ctl+alt+bs) from a
shell on that screen, the VGA attached screen comes back, but the A31p
laptop UXGA screen does not come back. Hmm. Interesting... if the ATI
RV200 FireGL 7800 in the A31p really did do a post, that means that it
my be some sort of hardware/timing issue to do with the TFT or
something. The only way to get the UXGA screen to work again is a
hardware master clear (i.e. hard reboot). Again, the system always
resumes, the attached VGA controller resumes, the shell I had on that
screen works fine, but nothing I could do (so far) would get the A31p
UXGA screen to come back alive, short of a reboot. I did try running the
Hardy screen resolution preferences tool from a launcher I put on that
screen, to no avail. Are there any other ways to kick the ATI controller
other than vbetool I wonder... I will give xrandr a try next time...

Hmmm. Perhaps I should give my sleep 5 thing a try. There must be some
ATI magic that needs to be added to the radeon driver... I wonder if the
fgrlx driver has this problem? Too bad it won't run on this system.

Thomas.

[Rolf Leggewie (r0lf)]

does this ever occur in precise or later?

[Rolf Leggewie (r0lf)]

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!