vbetool breaks resume on R50e
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
acpi-support (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
vbetool (Ubuntu) |
Fix Released
|
Medium
|
Rolf Leggewie |
Bug Description
My machine: https:/
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/
This bug was filed on Matthew's request in bug #18113
Related branches
description: | updated |
Matthew Garrett (mjg59) wrote : | #1 |
Reinhard Tartler (siretart) wrote : output of dmidecode | #2 |
- output of dmidecode Edit (11.6 KiB, text/plain)
As requested, the output of the command 'sudo dmidecode'
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : Re: R50e fails to resume: Green moon constantly blinking | #3 |
I can confirm this.
Reinhard Tartler (siretart) wrote : | #4 |
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) wrote : | #5 |
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
;;
in '/usr/share/
Also, what happens if you use 'Ctrl-Alt-
Changed in acpi-support: | |
status: | Unconfirmed → Needs Info |
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : dmidecode output | #6 |
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : lspci -n output of 1834-5us | #7 |
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : Re: R50e fails to resume: Green moon constantly blinking | #8 |
I must add that this worked great and without problems in 5.10
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : | #9 |
Setting experimental=0 in modprobe.
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : | #10 |
Is more info needed?.
Paul Sladen (sladen) wrote : | #11 |
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) wrote : relevant output in /var/log/messages | #12 |
- relevant output in /var/log/messages Edit (7.0 KiB, text/plain)
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) wrote : Re: R50e fails to resume: Green moon constantly blinking | #13 |
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_
i915_irq_
drm_ioctl+
do_ioctl+0x93/0xa0
vfs_ioctl+
sys_ioctl+
sysenter_
which is DRM related.
Angelo Lisco (angystardust-gmail) wrote : Re: R50e/i915 DRM module crashes on unhibernate. | #14 |
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) wrote : | #15 |
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.
Changed in xserver-xorg-driver-i810: | |
status: | Needs Info → Rejected |
Reinhard Tartler (siretart) wrote : kern.log on R50e | #16 |
- kern.log on R50e Edit (61.6 KiB, text/plain)
I don't have xorg-air installed, and my crash is not DRM related
Reinhard Tartler (siretart) wrote : Re: R50e fails to resume: Green moon constantly blinking | #17 |
It is not the DRM that is crashing for me, maybe it's the kernel which gets confused with interrupt routing?
Changed in xorg-air: | |
status: | Rejected → Unconfirmed |
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : what I got before using Xorg-air | #18 |
- what I got before using Xorg-air Edit (436.6 KiB, text/plain)
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) wrote : Another try | #19 |
- Another try Edit (16.4 KiB, text/plain)
This is a more recent try (using only standar stuff).
I clicked the Log out -> Sleep button.
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : vbetool crash | #20 |
- vbetool crash Edit (110.9 KiB, text/plain)
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_
May 20 06:50:05 milkyway kernel: [4294834.649000] EIP is at system_
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) wrote : Re: R50e fails to resume: Green moon constantly blinking | #21 |
I dont want to be a PITA but, any more info needed?
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : Script that successfully sleeps the system | #22 |
- Script that successfully sleeps the system Edit (455 bytes, text/x-sh)
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://
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) wrote : Re: R50e fails to resume: Green moon constantly blinking | #23 |
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/
echo -n mem > /sys/power/state
cat /var/cache/
rm -rf /var/cache/
/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) wrote : | #24 |
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/
Vladimír Lapáček (vil) wrote : dmidecode output for 1834S5G | #25 |
- dmidecode output for 1834S5G Edit (11.7 KiB, text/plain)
This is dmidecode for my Thinkpad R50e 1834S5G.
Vladimír Lapáček (vil) wrote : Log of dying gdm | #26 |
- Log of dying gdm Edit (7.6 KiB, text/plain)
And here is log captured when resuming my laptop. You can see the dying gdm there.
Paul Sladen (sladen) wrote : Re: R50e fails to resume: Green moon constantly blinking | #27 |
Vladimír Lapáček (vil) wrote : Xorg log | #28 |
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) wrote : Re: R50e fails to resume: Green moon constantly blinking | #29 |
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/
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) wrote : Re: [Bug 40621] Re: R50e Resume requires "VBERestore" "true" in xorg.conf | #30 |
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/
"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) wrote : Re: [Bug 40621] Re: [Bug 40621] Re: R50e Resume requires "VBERestore" "true" in xorg.conf | #31 |
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/
> "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:/
>
Reinhard Tartler (siretart) wrote : Re: R50e Resume requires "VBERestore" "true" in xorg.conf | #32 |
I tried both suggestions (Option "VBERestore" "true") and editing /etc/acpi/
Vladimír Lapáček (vil) wrote : Re: [Bug 40621] Re: R50e Resume requires "VBERestore" "true" in xorg.conf | #33 |
Please, try commenting oun the POST_VIDEO=true option (so that it looks like
#POST_VIDEO=true) in the /etc/defaults/
mine.
On 6/25/06, Reinhard Tartler <email address hidden> wrote:
>
> I tried both suggestions (Option "VBERestore" "true") and editing
> /etc/acpi/
> from suspend. :(
>
> --
> R50e Resume requires "VBERestore" "true" in xorg.conf
> https:/
>
Reinhard Tartler (siretart) wrote : Re: R50e Resume requires "VBERestore" "true" in xorg.conf | #34 |
Ok, I tried a bit further, and it seems, that the order in /etc/acpi/
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : | #35 |
- Script for proper suspending in R50e Edit (547 bytes, text/x-sh)
This script fixes the problem on my R50e :).
description: | updated |
Reinhard Tartler (siretart) wrote : | #36 |
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) wrote : | #37 |
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/
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
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/
# R50e
;;
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?
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) wrote : | #40 |
+1:
On my R50e with Edgy, I just need Option "VBERestore" "true" in xorg.conf and POST_VIDEO=false in /usr/share/
Then suspend to RAM works perfectly. Can we get this working out of the box before Edgy's finalised?
Changed in acpi-support: | |
status: | Unconfirmed → Confirmed |
Reinhard Tartler (siretart) wrote : | #41 |
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.
description: | updated |
Axel Bojer (axelb) wrote : | #42 |
See also:
https:/
I added some relevant information there, perhaps it will also be important for this bug.
Thomas Jacobson (thomas-tcjnet) wrote : Re: vbetool breaks resume on R50e (and A31p too) | #43 |
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/
Here is my /etc/acpi/
#!/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) wrote : | #44 |
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/
GioSico (john-giosico) wrote : | #45 |
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/
ln -s /etc/acpi/
Also posted in bug https:/
GioSico (john-giosico) wrote : | #46 |
- dmidecode.txt Edit (5.9 KiB, text/plain)
Ok I have tried everything described above and suspend still does not work ...
However setting /etc/acpi/
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) wrote : | #47 |
Yannick (splitsch) wrote : | #48 |
Hello!
The bug still exist on a fresh installed Ubuntu Gutsy beta, and on an up-to-date Gutsy.
Bye
Mahdi (mahdi-hates-spam) wrote : | #49 |
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) wrote : | #50 |
The xorg option is now ignored, that produce corrupted graphics always.
Anton (feenstra) wrote : | #51 |
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_
Is that what you meant? If so, where/how to set it?
Yannick (splitsch) wrote : | #52 |
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) wrote : Re: [Bug 40621] Re: vbetool breaks resume on R50e | #53 |
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_
# Should we attempt to warm-boot the video hardware on resume?
POST_VIDEO=false
# Save and restore video state?
SAVE_VIDEO_
# 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_
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/Bioinform
|( | )| | | De Boelelaan 1083A - 1081 HV Amsterdam - Netherlands |
| \_/ \_/ | | | Tel +31 20 59 87783 - Fax +31 20 59 87653 - Room P136 |
| | <email address hidden> - www.few.
| | "A Lady Shaves Her Legs" (C. Meijering) |
|______
Yannick (splitsch) wrote : | #54 |
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) wrote : | #55 |
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/Bioinform
|( | )| | | De Boelelaan 1083A - 1081 HV Amsterdam - Netherlands |
| \_/ \_/ | | | Tel +31 20 59 87783 - Fax +31 20 59 87653 - Room P136 |
| | <email address hidden> - www.few.
| | "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_
# Should we save and restore state using the VESA BIOS Extensions?
SAVE_VBE_
# SAVE_VBE_STATE=true
# The file that we use to save the vbestate
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_
# SAVE_VIDEO_
# 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_
# DOUBLE_
# Set the following to "platform" if you want to use ACPI to shut down
# your machine on hibernation
HIBERNATE_
# Comment this out to disable screen locking on resume
# LOCK_SCREEN=true
# Uncomment this ...
Sebastian Urban (surban) wrote : | #56 |
- wait 2 sec after resume (put this into /etc/acpi/resume.d and make it executable) Edit (75 bytes, text/x-sh)
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_
Hope this helps.
Yannick (splitsch) wrote : | #57 |
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) wrote : | #58 |
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) wrote : | #59 |
Got it working again, I tweaked /usr/share/
# R50e
;;
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/
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : | #60 |
Now on Ibex, it's broken again :). Hardy was fine with my last comment. Now it's broken again.
Changed in vbetool: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Bryce Harrington (bryce) wrote : | #61 |
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: | |
status: | Confirmed → Triaged |
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : | #62 |
It broke for me this Friday after a reboot, let me try again today and confirm.
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : | #63 |
Bryce, my tip:
# R50e
;;
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) wrote : | #64 |
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.
start.
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/
(Closes: #459326)
* Add rotatescreen.sh, asus-rotate script to support Asus R1F tablet
screen rotation.
(Closes: #450531)
* Reinstate thinkpad_
working". This was dropped in 0.106 perhaps too hastily.
(Closes: #481253)
[ Raphael Hertzog ]
* Add a new SKIP_INTERFACES variables in /etc/default/
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
Changed in acpi-support: | |
status: | Triaged → Fix Released |
Yannick (splitsch) wrote : | #65 |
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.
Changed in acpi-support: | |
status: | Fix Released → Confirmed |
diegoe (diegoe-deactivatedaccount-deactivatedaccount) wrote : | #66 |
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) wrote : | #67 |
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/
<!-- X31, T30 , A31p-->
<match key="system.
<merge key="power_
type="bool"
<merge key="power_
type="bool"
<merge key="power_
type="bool"
<merge key="power_
type="bool"
</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) wrote : Re: [Bug 40621] Re: vbetool breaks resume on R50e oops... | #68 |
Oh darn! No sooner than I say the hal quirk fixes to
20-video-
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) wrote : | #69 |
does this ever occur in precise or later?
Changed in vbetool (Ubuntu): | |
assignee: | nobody → Rolf Leggewie (r0lf) |
status: | Confirmed → Incomplete |
Rolf Leggewie (r0lf) wrote : | #70 |
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!
Changed in acpi-support (Ubuntu): | |
status: | Confirmed → Fix Released |
Changed in vbetool (Ubuntu): | |
status: | Incomplete → Fix Released |
Can you attach the output of the dmidecode command?