Darter suspend, hibernate broken

[cboettig]

Suspend and hibernate fail to work on new (5-12-07) Darter w/ Feisty

[Thomas Aaron (tom-system76)]

I've been able to duplicate this problem on our shop Darter.

The Darter does resumes from Suspend, but does not turn up the brightness on the LCD. This problem can be worked around by manually turning up the display brightness after a suspend using the Fn+F5 and Fn+F6 keys.

Unfortunately this bug seems to be related to Bug #114677, which does not allow some Darter users to manually turn up the display brightness using Fn-F5 and Fn-F6.

Please see Bug #114677 for a temporary work around until we can get this problem solved.

Please Note: After implementing the work-around, you may have to press the F6 button several times to turn the display up enough to see the screen, as the Resume function seems to turn the LCD down to zero (the lowest setting).

Best,
Tom

[cboettig (cboettig)]

This does not seem to be the problem for me. I implemented the workaround and can adjust brightness with f5, f6 keys, though not over the full range that I can with the software (power use options). When I suspend, f6 does not help, the screen remains totally black. Further, the machine does not appear to respond to ctr+alt+backspace or ctr+alt+delete. The only thing I can do is a hard reboot.

Hibernate seems to error while going into hibernation, presenting screen distortion.

I see that the system76 driver was updated today (05-16-07). Is this related?

I'm happy to see responses to these bug reports already up, you guys are awesome.

-Carl

[sherrardb (sburton-launchpad)]

not sure if this is going to end up requiring a separate bug report, but this is what i've found. for me, there are at least two different failure modes when the laptop does not successfully come back from suspend. the first one, which i do believe can be solved with the work around mentioned in Bug #114677, is simply related to the lcd backlight not coming up fully after resume. i am able to differentiate this case because even without the backlight, you can see that the display is redering if you look at an appropriate angle. if i can ever reproduce this failure mode by itself, i will test the work around.

the more common failure for me, and i believe the problem that Carl is experiencing, is related to gdm/xorg not coming back up successfully after resume. here is how i initially diagnosed that this was the issue:

1) connect the laptop with the wired ethernet (i couldn't get this to work over the wireless)
2) find the laptop's ip address and confirm that you can ssh onto the laptop from another machine. if not, install and configure openssh-server
3) press fn+f1 to suspend
4) wait a few seconds after it suspends, then press any key to resume
5) use nmap or ping to confirm when the ethernet adapter comes back up
6) ssh onto the laptop
7) run top

i was seeing gdm, xorg, and it's related processes chewing up all of the cpu, with load averages sometimes in the 4-7 range. my initial investigation seems to point to a problem with the xorg i810 driver. i hope to post more information when i have it. even without ssh'ing onto the machine, i discovered a simple test that will likely indicate that you are experiencing the same problem. i call it the "place your right hand near the cpu heat exhaust" test. before fully diagnosing this, i had noticed that the temperature output was very high for a machine fresh from suspend and therefore pretty much idle. this also jibes with the fact that the cpus are basically pegged.

and finally to confirm that x was truly at fault in this case i performed all of the following steps above, except that instead of logging into the graphical interface, i logged in to a tty (ctrl+alt+f1) and shut down gdm (/etc/init.d/gdm stop) before triggering the suspend. then when i ssh'ed onto the laptop after resume, i simply executed the brightup.sh script from Bug #114677, and viola, i was back in business, with my tty restored, and no worse for the wear.

Carl, if you're listening, could you try this to confirm whether this is the same problem that you are having? i'm going to dig a little more to see if i can further diagnose the gdm/xorg problem.

[cboettig (cboettig)]

sherrardb:

Sorry that I did not get a chance to test as you propose above. My problem has been fixed by a fresh install (using kubuntu cd, though I don't believe that mattered). I now have the more mundane suspend problem of the screen brightness, which the workaround Bug #114677 fixes. Bug #114677 has more discussion of this issue for anyone following along.

-Carl
ps I'm not Carl Richell, I'm just a normal user. maybe i should sign with my username cboettig to avoid possible confusion ;-)

[sherrardb (sburton-launchpad)]

i'm glad you cleared that up. i would not have known, but it probably doesn't matter for the purposes of these conversations. you should definitely check back on Bug #114677, as i have explained how i got the brightness keys working natively. i'm personally far enough down this i810 driver rabbit hole that i think i'll work on it a little more before i reinstall. it would be really nice to know that combination of the i810 driver and the other fresh install parts of the configuration make this work, and therefore what goes wrong to break it.

[Christopher (christopher-m-werner)]

Well, after doing a bit of searching I was able to make some headway using a suggestion from a German wiki:
http://de.wikibooks.org/wiki/Asus_W3N-Kompendium:_Ubuntu_Suspend_to_Ram

Basically it suggested setting the following values in /etc/default/acpi-support to
# Uncomment the next line to enable ACPI suspend to RAM
ACPI_SLEEP=true
# 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
# Should we switch the screen off with DPMS on suspend?
USE_DPMS=false

This seemed to allow the system to sleep, and recover at least a little bit. When it came back, the backlight was _off_ and refused to come back on until I performed a hard reboot. fn+F7 (which usually works correctly for me) would not restore the backlight. I am having the problems described in Bug #114677, but the workaround given there (which also usually gives me control over my backlight) did not have any effect while in this state.

I checked that xbindkeys was still running as a service (it was), and I went as far as to try manually running the brightup.sh script, again to no effect.

Not sure if anyone else has any ideas on where to go from here.

[Christopher (christopher-m-werner)]

I have it working!

It still requires using the solution listed in Bug #114677 so I'd like a more complete solution but:
Modify the following setting in /etc/default/acpi-support to:
# Uncomment the next line to enable ACPI suspend to RAM
ACPI_SLEEP=true
# 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
# Should we switch the screen off with DPMS on suspend?
USE_DPMS=false
# This is needed for some hardware, but should be unnecessary on most.
DOUBLE_CONSOLE_SWITCH=true

Then hitting either F5 or F6 will light up the screen. Hopefully this will help someone else.

I still really want a solution to the fn+F5/6 bug though...

I'm also wondering, for people who's laptops have worked 'out of the box' how are their acpi-support files set? I'd like to pin-point the root cause of this.

My system BIOS is v302
VGA BIOS 1256.I06107.006

I've also wondered if it's a BIOS dependent issue like someone else suggested.

[sherrardb (sburton-launchpad)]

yes the buttons work natively with the 305 bios. i booted up, switched to a terminal, killed gdm and acpi just to double confirm this, and i can still adjust the brightness.

here's my post about the update from Bug #114677:

also, and believe me i'm not advocating this, but i was able to get the brightness keys working without the work around by flashing to the latest bios, version 305 (z35f305ag.zip). it was a bit of a white-knuckle experience.

the built-in utility within the bios is basically a simple text-based directory navigator and file selector. but since it says doesn't support usb, cdrom, or secondary hard drive, you basically have to have some kind of windows partition near the front of your hard drive. i have a fat32 partition near the end of the drive that it didn't even see. but surprisingly enough, it seems to read ntfs. and i have one of those about 10G from the front of the drive. so i downloaded and extracted the all of the bios updates, just in case, then rebooted and pressed f4 to get into the update utility. once there, i navigated to and selected the file, z35fag.305, then after it started to apply the update, in a moment of stupidity, i turned my attention away for a few seconds. well when i turned back the laptop had powered itself down. why, i didn't know. so i gritted my teeth and pressed the power button. after way too many seconds of just the fan spinning, it finally brought up the post screen. so i exhaled, said a little prayer of thanksgiving, and went in to confirm the bios settings. after that i booted up, killed off xbindkeys, and tested my brightness keys. i don't know if this also fixes anything else, but i am still working on my suspend/resume issues.

so, as i indicated, it is not straight-forward for us linux users, but if you're a dual-booter like me, then it's doable.

[Bret Towe (magnade)]

I'm seeing suspend issues on my darter
hibernate is working but I've not tested it very much as I don't need it as much as suspend

If others are having hibernate issues one thing I did without testing before hand was upgrading
the kernel currently I'm on 2.6.22-rc2 with cfs patched in tho I doubt that bit would make a difference

the /etc/default/acpi-support bits commented on above made no change in how my machine worked
suspend is still broken and hibernate is happy

and while the new bios (v305) helps brightness keys it seems to do nothing for suspend

[sherrardb (sburton-launchpad)]

Bret:

have you taken a look at my post above (#3)? using one of those methods, you may be able to further determine whether it is simply an lcd issue, or if xorg is unhappy. the simplest test, now that you've got the brightness keys working natively, is to log out of gnome and kill gdm before suspending and resuming to see if you can get back to a terminal prompt just by adjusting the brightness. the first test is a lot more involved, but the information is more conclusive.

good luck.

[Bret Towe (magnade)]

sherrardb:

I did try suspending from 'recovery' mode which of course doesn't have x loaded and it still didn't resume
as for logging in and such I was planning on tinkering with that tomorrow

[Carl Richell (carlrichell)]

I can confirm Christopher's adjustments fixed Suspend on my Darter:

Modify the following setting in /etc/default/acpi-support to:
# Uncomment the next line to enable ACPI suspend to RAM
ACPI_SLEEP=true
# 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
# Should we switch the screen off with DPMS on suspend?
USE_DPMS=false

I did not have to change the below line however (left commented as shown).

# This is needed for some hardware, but should be unnecessary on most.
#DOUBLE_CONSOLE_SWITCH=true

This is on the current Ubuntu kernel:
$ uname -r
2.6.20-16-generic

Once I resume the screen is dark with the password prompt barely visible. Using FN + F6 increases the brightness.

[Carl Richell (carlrichell)]

Thanks to Christopher and sherrardb we also have a fix for the dark password prompt after resume.

sudo gedit /etc/acpi/resume.d/89-brightup.sh

Paste the following into the file:

#!/bin/sh
#filename: brightrestore.sh

brtNum=`cat /proc/acpi/asus/brn`
echo $brtNum > /proc/acpi/asus/brn

Save and close.

[bj mccormick (bjmccormick)]

This has just started happening to me on the newer Gutsy kernels. Suspend always worked properly before though... I'll try the things listed here to see what happens

[Thomas Aaron (tom-system76)]

We're in the middle of gutsy testing now.

----- Original Message -----
From: "bj mccormick" <email address hidden>
To: <email address hidden>
Sent: Tuesday, October 16, 2007 12:46:16 PM (GMT-0700) America/Denver
Subject: [Bug 114675] Re: Darter suspend, hibernate broken

This has just started happening to me on the newer Gutsy kernels.
Suspend always worked properly before though... I'll try the things
listed here to see what happens

--
Darter suspend, hibernate broken
https://bugs.launchpad.net/bugs/114675
You received this bug notification because you are a member of System76
Bugs, which is the bug contact for System76.