Intrepid regression: Suspend from Gnome menu fails to resume on Twinhead H12Y clone laptop

Bug #305339 reported by JenniferHodgdon
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
hal (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: acpi-support

I have an Everex StepNote 2053 T laptop (see below **) that doesn't resume after a suspend in Ubuntu 8.10 Intrepid; worked fine in Hardy.

More details: I recently updated from Hardy to Intrepid, using the Update functionality of the GUI-based package manager. I've since updated to the latest package releases, and am running the 2.6.27-9-generic kernel at the moment (will attach more detailed system info). I have the SDHCI and SDHCI-PCI modules blacklisted (see Bug #187671), but other than that it's a fairly standard Intrepid install. I'm apparently running version 0.114 of the acpi-support package.

When I boot into this kernel, the earlier 2.6.27-7-generic kernel, or a 2.6.27.7 kernel I compiled form kernel.org source, and I suspend the laptop from the System / Shut Down menu item in Gnome, the laptop fails to resume. Booting into an old 2.6.26 kernel I compiled myself from kernel.org source, suspend/resume works. It also used to work fine in Hardy using kernels supplied by Ubuntu (which were conveniently erased when I upgraded to Intrepid) when I was still running Hardy.

What I'm seeing with the current kernels, after I suspend and then hit the space bar to try to resume, is a blinking cursor in the upper-left of the otherwise black laptop screen. In fact, before I added this line to my startup sequence
    echo 3 > /proc/sys/kernel/acpi_video_flags
I couldn't even see the cursor -- the screen was just black (I added this line to startup because a friend with a different laptop was seeing a black screen and this fixed his problem, but it didn't fix my problem, just made the cursor visible). The fan and drives start up and make noise, but the laptop isn't usable.

I've tried control-alt-f1 (and other f-keys) and control-alt-backspace, but they have no effect.

I will attach lspci output and some other system output, and do some more debugging (I found debugging guides https://wiki.ubuntu.com/DebuggingKernelSuspend and http://ubuntuforums.org/showthread.php?p=3066404)... will report these in separate comments, coming shortly, but I wanted to get the bug reported first.

** Here is a list of laptops which are apparently all clones of this one:
 * Averatec 2460
 * Everex Stepnote SA2050
 * Everex Stepnote SA2050T
 * Everex StepNote SA2052T
 * Everex StepNote SA2053T
 * Philips Freevents x52
 * Philips Freevents x53
 * Philips Freevents x54
 * Philips Freevents x55
 * Philips Freevents x56
 * Twinhead H12Y

Revision history for this message
JenniferHodgdon (yahgrp) wrote :
Revision history for this message
JenniferHodgdon (yahgrp) wrote :
Revision history for this message
JenniferHodgdon (yahgrp) wrote :

OK, this is interesting. I was playing around with some of the debugging suggestions on this page http://ubuntuforums.org/showthread.php?p=3066404

I found that after a reboot (to make sure I had reset the system to its normal state), If I went to a terminal window and typed
   sudo /etc/acpi/sleep.sh force
everything worked fine. There were a few warnings on the screen (e.g. that /etc/network/run/ifstate file didn't exist, and a couple "Function not supported lines, and on resume, module acpi_sbs not found), but everything resumed without any problems.

So it appears that the problem is with the Gnome menu item suspend, rather than with the sleep.sh script.

If I can figure out how, I will change the package this is reported against, but if I can't figure it out, can someone do that? I don't think the problem is with ACPI if sleep.sh works, is it? And it doesn't look like any of the debugging things will be all that useful, because all of them are debugging problems with sleep.sh and not with the Suspend menu item in Gnome.

Anyway, I'm happy to run other tests, just add a comment and I'll see what I can do.

Revision history for this message
JenniferHodgdon (yahgrp) wrote :

Changed package to gnome-power-manager because the sleep.sh script works, but the Suspend command from System / Shutdown in Gnome menus doesn't work.

Revision history for this message
Eran Chen (eranc) wrote :

Try runing:
` dbus-send --system --print-reply --dest="org.freedesktop.Hal" /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0 `

and see what happens .

If it doesn't work then I should say that the problem is in hal and not in gnome-power-manager ( Since gpm runs the correct command but the command is the problem)

Revision history for this message
JenniferHodgdon (yahgrp) wrote :

I tried the command in the previous comment

dbus-send --system --print-reply --dest="org.freedesktop.Hal" /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0

The result was the same as running from the Gnome menu: failure to resume (as described in the bug description).

So I have changed the package to hal, on the advice of the previous comment's poster.

Revision history for this message
JenniferHodgdon (yahgrp) wrote :

Just a note: Today I built a 2.6.28 kernel from the kernel.org source, and I'm still having the same sleep problems reported here.

Revision history for this message
JenniferHodgdon (yahgrp) wrote :

I did some more playing around with this today. I'm now running the 2.6.27-11-generic kernel, and I have also tried 2.6.28 and 2.6.29-rc5 (the latter two compiled from kernel.org source). They all behave similarly, but the testing reported here was with the 2.6.27-11-generic kernel from Ubuntu.

Some things I've noticed:

a) The sleep.sh script is not working consistently for me lately, when run from a terminal window inside Gnome. I can suspend (the computer shuts down to its suspended state, and the blue LED blinks, so the hardware must think it's asleep). But it often doesn't resume past the blinking cursor (see description above). Sometimes it does boot up again, but I get a Gnome login prompt and I've lost my previous Gnome session, so that's not very good.

b) Using the "Suspend" menu items in the Gnome GUI consistently fails to resume to a booted state at all, or sometimes I might get the blinking cursur.

c) If I use control-alt-f1 to get to the tty1 console from Gnome, log in at the console prompt, and run sleep.sh from there, I can consistently sleep and resume.

c) After sleep/resume from tty1 console, I can use alt-f7 and get back to my previous Gnome session (yeah!! It actually resumes! I have a work-around!). Usually the network is not properly connected, but after taking care of that, I can work as normal. (This is what I normally do when I first boot up the computer after a shutdown, so it is not a surprise -- I use a custom network config.)

So it seems as though the problem has to do with suspending from Gnome, and resuming straight to Gnome. Does that tell anyone anything? Any troubleshooting ideas?

Revision history for this message
JenniferHodgdon (yahgrp) wrote :

One more correlary.

There doesn't seem to be a hibernate option from the Gnome menu system any more.

When I tried the /etc/acpi/hibernate.sh script from a terminal window within Gnome, the machine did not hibernate to the point of turning off. It partially turned off: the Gnome display went dark, and I was unable to recover my Gnome session (or any Gnome session), but the computer was still on. Eventually escaped to tt1 and did sudo halt, and then rebooted, since alt-f7 just got me back to the dark screen, not Gnome.

I also tried sudo /etc/acpi/hibernate.sh from a TTY window. That worked fine - the machine hibernated, and woke up fine.

So again, hibernate seems to have the same problem as sleep: it works OK if run from the /etc/acpi scripts from a TTY console window, but not if run from within Gnome.

Revision history for this message
Tomas M. (el-dragon) wrote :

jennifer, i dont know if you managed to fix this, but under archlinux i had this very same problem (same laptop)

i had to manually remove some modules to get it to resume correctly. so i resorted to creating a special hook for pm-suspend (adding the modules to the suspend_modules viariable didnt cut it for me).. here it goes:

file located at /etc/pm/sleep.d/ should be +x

Revision history for this message
JenniferHodgdon (yahgrp) wrote :

Thanks, that is very good to know. If I still have this problem when I upgrade to Jaunty (any day now), I'll try your solution. I've just been living without sleep.

Incidentally, and I didn't apparently mention it above, with one of the later kernel updates in Intrepid or something else I or another update did, my ability to control-alt-f1 and then get back to Gnome with alt-f7 went away, and so I am unable to use my escape-to-terminal method of suspending. Sigh. I have just had to turn the computer completely off instead of suspending.

Anyway, I haven't yet tried your additional module turn-off, eldragon, but I'll give it a try if Jaunty still has these suspend issues.

Revision history for this message
dino99 (9d9) wrote :
Changed in hal (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.