suspend works on tribe 5, fails with updates since then, vaio TZ190N

Bug #136688 reported by Steve Alexander
12
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Won't Fix
Undecided
Unassigned
linux-source-2.6.22 (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Suspend to ram worked fine on this sony vaio tz190n with the gutsy tribe 5 intel 32 bit CD.

I installed the updates since then, and now, suspend to ram no longer works. The computer never suspends, although the exact behaviour varies according to whether I'm running desktop effects or not.

If I'm running desktop effects, then the machine stalls as the "suspend / shutdown" graphical options window is fading out.

If I'm not running desktop effects, then the screen blanks as I'd expect, but then the machine never shuts off into suspend mode.

Revision history for this message
TJ (tj) wrote :

It is possible you're affected by the issue dealt with in another bug report. Please check the (simple) solution and report back.

[gutsy] resuming from suspend/hibernate broken

https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/136453/comments/19

Revision history for this message
Steve Alexander (stevea) wrote :

I checked the /etc/acpi/prepare.sh file, and the space is already present. I have acpi-support 0.99.

I just tried to reproduce the problem, and I'm seeing similar results as I reported originally. The only change is that I get the same behaviour with and without desktop effects now: the screen blanks as I'd expect, but then the machine never shuts off into suspend mode.

Revision history for this message
TJ (tj) wrote :

Okay, lets try the other likely candidate, bug #136433, from this past week that we've identified and fixed.

It is possible automatic updates have already applied this one and the cause is something else, but please check the version of:

$ dpkg-query -l 'powermanagement-interface'

ii powermanagemen 0.3.17 platform neutral powermanagement interface

If you have an older version please check the bug-report above and report back.

Revision history for this message
Steve Alexander (stevea) wrote :

I have powermanagement-interface 0.3.17.

Revision history for this message
TJ (tj) wrote :

In these situations I usually try a manual sleep and monitor the script as it runs.

Firstly I edit /etc/acpi/sleep.sh and add "set -x" at the start of the file. Then I switch to a virtual terminal and run:

$ sudo /etc/acpi/sleep-sh force

And monitor the output. If there are problems with the screen blanking and not restoring, I use:

$ sudo /etc/acpi/sleep-sh force >/tmp/sleep.log

or, if the PC locks up and has to be reset:

$ sudo /etc/acpi/sleep-sh force >/var/log/sleep.log

If you could try this maybe we can determine if the issue is in gnome's power-management handling or is a wider problem.

Revision history for this message
Steve Alexander (stevea) wrote :

Okay. I added 'set -x' on a new line immediately after the '#!/bin/bash' line.

Then I ran "sudo /etc/acpi/sleep.sh force" from a virtual terminal. Various text appeared on the screen, then the screen went blank. After several minutes, the screen remained blank, but the laptop was still not suspended (power light glowing green, not pulsating yellow).

I could press num lock, and see the light go on and off.

I cut the power, and did a hard reset.

Next, in a virtual terminal, I ran "sudo -s" followed by "/etc/acpi/sleep.sh force > /var/log/sleep.log".

Same behaviour as before (unsurprisingly). Hard reset, check the log file. The only line in it is "* Shutting down ALSA... ^[80G ^M^[74G[OK]".

I try "/etc/acpi/sleep.sh force 2> /var/log/sleep.log", and get 232 lines of log output, attached (with MAC addresses removed).

Revision history for this message
TJ (tj) wrote :

Thanks for that Steve, it helps narrow down the options quite a bit. The good news is the problem can be reproduced using the scripts so it isn't just a Gnome issue - this makes it easier to debug.

Secondly, The log shows the PC is told to turn off but refuses so that takes us into the realms of the ACPI Suspend code that I've become quite friendly with recently, chasing down a very weird suspend-the-resume-immediately issue.

To get to the bottom of this we may need to run one of my custom-patched ACPI debug kernels that prints to the kernel-log right up to the last ASM instruction before the hardware is put to sleep. I've found it invaluable at working out where the issues lie quickly and efficiently.

However, before that, I'd like to try out a new technique I've developed if you'd agree to be the guinea-pig.

I've just started using SystemTap modules (http://sourceware.org/systemtap/) to non-invasively log what a standard-build kernel is doing. With your permission I'd like to create a SystemTap module for your 32-bit tribe 5 ( 2.6.22-10-generic ?) install that you can run to capture more information on where the kernel is getting to. It might need a few iterations of the module-script to get it peeking into the correct places.

Revision history for this message
Steve Alexander (stevea) wrote :

The machine is using 2.6.22-10-generic.

I use another computer to get work done, so there's no problem experimenting with this one. I agree to be the guinea pig for trying out SystemTap or other custom kernels.

Revision history for this message
Brian Murray (brian-murray) wrote :

Changing the bug status to Incomplete as information is currently being gathered about it and it is no longer new.

Changed in linux-source-2.6.22:
status: New → Incomplete
Revision history for this message
Steve Alexander (stevea) wrote :

I'm still available to run that custom kernel, and look into it.

I confirm that suspend on this laptop is still regressed from working on tribe 5 to hanging with blank screen and without suspending with current gutsy.

Revision history for this message
Ryan W. (drwillhoit) wrote :

My TZ150 exhibited the same problems. However, I was able to adjust the configuration a bit and get things to work:

Edit /etc/default/alsa
> sudo vim /etc/default/alsa

Change
    force_unload_modules_before_suspend=""
to
    force_unload_modules_before_suspend="all"

Revision history for this message
Steve Alexander (stevea) wrote :

Thank you Ryan! I added this line in /etc/default/alsa, and my machine now reliably suspends and resumes.

Revision history for this message
Steve Alexander (stevea) wrote :

See also bug 192935.

Revision history for this message
TJ (tj) wrote :

Work-around is to unload ALSA modules prior to suspend. Updated report using latest kernel is needed to determine if this is still an issue.

Changed in linux-source-2.6.22:
assignee: intuitivenipple → nobody
Revision history for this message
Launchpad Janitor (janitor) wrote : This bug is now reported against the 'linux' package

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

*This is an automated response*

This bug report is being closed because we received no response to the previous request for information. Please reopen this if it is still an issue in the actively developed pre-release of Jaunty Jackalope 9.04 - http://cdimage.ubuntu.com/releases/jaunty . To reopen the bug report simply change the Status of the "linux" task back to "New".

Changed in linux:
status: Incomplete → Won't Fix
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.