Resume after suspend not working - Toshiba Tecra R700

Hi Daniel,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

Jeremy,

Thanks so much for looking into this.

I tried the mainline kernels as suggested. I tried these two:

http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/linux-image-2.6.38-999-generic_2.6.38-999.201101261132_i386.deb
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/linux-image-2.6.38-997-generic_2.6.38-997.201101270909_i386.deb

Both of these exhibit the same problem.

I'm removing the needs-upstream-testing tag as indicated and await further information on this report.

Thanks again!

Also, the latest SRU kernel in proposed does not alleviate the issue : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/723335 (linux 2.6.35-27.48)

Tried with this kernel from feb-28:

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/2011-02-28-natty/linux-image-2.6.38-996-generic_2.6.38-996.201102280905_i386.deb

We still get the same unable-to-resume behavior.

Putting back to New, as the reported provided the needed information

Please, assign this bug to the corresponding team.

Given this bug has been found, and raised for last 6 weeks by hardware certification team, it should have been marked as confirmed, and indicated as a blocker. (status has been changed to confirmed, and milestone added).

If this system is certified for maverick, presumably suspend/resume worked at some point? If so, do we know a specific version of the kernel for which suspend/resume worked properly?

If we have a known-working kernel version then we can do a bisect to track down the commit that broke things for this machine. Even better if we know the first non-working kernel version.

Hi Seth,

I installed Maverick on this system and tried these two kernels - the first is the stock 2.6.35 kernel as shipped with Maverick, the second is the latest one as obtained via dist-upgrade.
2.6.35-22-generic (buildd@vernadsky) #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010
2.6.35-28-generic (buildd@roseapple) #49-Ubuntu SMP Tue Mar 1 14:40:58 UTC 2011

Sadly, with both of these, the system exhibits the same behavior when trying to resume from suspend.

The certificate notes state "This system requires the latest updates on Maverick as of appearance of this certification for graphics, suspend and hibernation to work". The certificate was issued with the system running kernel 2.6.35-23.40.

This behavior would suggest that suspend was broken (as we've observed this problem also on Lucid), then got fixed on the 2.6.35-23 release, and *then* got broken again between that and 2.6.35-28.

I'll try to track down and install that particular kernel, retest and report back here.

adjusted status to incomplete as we are waiting for an update. I've also re-targeted this to natty-updates for SRU.

~JFo

Hi, I installed Maverick on this machine, applied all the updates, and tested with the kernel that's supposed to be good (instead of the latest one). This is the kernel I used:

Linux 201010-6637 2.6.35-23-generic #41-Ubuntu SMP Wed Nov 24 10:18:49 UTC 2010 i686 GNU/Linux

However I'm still seeing the same behavior (no resume, system is unresponsive, fans spin up to top speed).

I tried using xforcevesa modeset as kernel parameters too, to rule out a possible problem with the display, but the faulty behavior persists.

It's admittedly not the very same that was used when certifying (that was #40) but I don't know how likely it is that the problem was fixed between -22 and -23.40, then reintroduced in -23.41.

That's too bad, because if we have a kernel that works it makes things much easier :-)

The next thing I'd suggest is going through the steps in the following two pages and see if you can get any useful information.

https://wiki.ubuntu.com/DebuggingKernelSuspend
https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume

Thanks!

Daniel - please can you do as suggested by Seth

Hi Seth,

I followed the procedure from DebuggingKernelSuspend. After setting pm_trace to 1 and suspending, the power light pulsates to indicate the system apparently entered suspend mode. When I press the power button, the power light turns green and the system seems to spin up, but there's no display and no actual response, the fan revs up and I'm forced to keep the power button pushed down to power off. I powered up immediately and obtained dmesg. I see this:

Magic number: 7:118:33

However there's no "hash matches" line so I think there's no useful information from this :(

I also tried booting with no_console_suspend an issuing pm-suspend from the console, there's no diagnostic text or messages at all in the console, the system just enters suspend mode.

Let me know if there's anything else I could try.

Thanks!

I have the exact same symptoms in natty with Lenovo X61T.
- Goes into suspend alright, but resume only spins fan up, theres is no display and sleep indicator is still on.
A hard reset is needed.

Havent tested hibernation though.

It used to work in 10.10.

Same problem with HP DV6 2113sa, though I have not tried teh mainline kernel yet.

Sounds like same problem with 11.04 Natty running 2.6.38-8-generic on AMD. This is on a Gigabyte MB running latest BIOS.

pm_suspend log appears to be fine. power on, fans come on, but no boot.

Keith

OK, I have tried both proposed and mainline (2.6.38-5) kernels. The problem is still present with both of them. I have tried to debug teh resume problem following https://wiki.ubuntu.com/DebuggingKernelSuspend, but I am not sure it gave me anything. Anyway I am attaching the dmesg.txt

On my problem, it is the BIOS. I am running an X2 AMD chip and was running a BIOS that allowed me to unlock the 2 extra cores on the die. With this BIOS, it will not wake up from an S3 suspend. With the normal BIOS, it works as expected. Suspends and resumes with no issues. I have contacted Gigabyte.

After upgrading from 10.10 to 11.04 this morning, I have the same problem on a desktop system with an Intel Core-i7 920. Suspending to disk works fine, but resuming hangs with a blank blue screen. The hard-drive light is steady for a while as it presumably loads the hibernate image, but then goes off and nothing happens. I have to hit Ctrl+Alt+Del to reset the system, at which point it does a fresh boot and comes up normally. Suspend to RAM works just fine. Suspend to disk used to work fine with the grub command-line option of acpi_mode=nonvs. However, that doesn't seem to work with Natty. Adding "nomodeset" doesn't help either.

Output of 'cat /proc/cmdline': BOOT_IMAGE=/vmlinuz-2.6.38-8-generic root=UUID=2a105d39-28d4-46c7-9136-f8cdce22a9c4 ro quiet nomodeset

Output of 'cat /etc/initramfs-tools/conf.d/resume': RESUME=UUID=e72b1a02-be53-4e4a-b746-a49f25b8640e

Resume from suspend was being broken on my laptop for about half a year. I've just found the http://ubuntuforums.org/showthread.php?t=782782 thread and written the following script which works like a charm.

#!/bin/bash
gnome-screensaver-command -l
sudo /etc/acpi/sleep.sh force

I'm currently running Natty and using the radeon driver. Hope this helps someone.

Back to confirmed, as the reported replied to the question

Back to confirmed

To everyone who posted a "me too" comment: These sorts of bugs tend to be very specific to a hardware configuration or bios, so unless you have the exact same machine as in the original report there's a very strong chance that your problem is not the same. Please open new bugs for your problems by running 'ubuntu-bug linux' from a terminal.

@Daniel:

Toshibas are notorious for having bios issues, so there's a pretty good chance that the bios is to blame here. The first thing you might want to do is check for an bios update, although they can often be tricky to apply under Linux. Past that, here's a few wild guesses based on past experience.

If you leave the machine sitting for 10 minutes or so after starting the resume, does the resume eventually finish? This behavior has been observed on some Toshibas. It's a bios problem that we can't really fix, but there's a workaround that might work.

Here's a list of kernel command line options you might try to see if they make any difference.
* nohz=off
* highres=off
* nohz=off highres=off
* intel_idle.max_cstate=1
* intel_idle.max_cstate=0
* nolapic_timer
* acpi_skip_timer_override

Those are things that have been known to work around bios bugs on various machines. Let me know if any of them work, and we might be able to dig in further.

Colin King is also working on some stuff to help with suspend/resume debugging for Oneiric, and as that comes together we might have some more techniques for getting information out of the machine.

Thanks!

@Seth Forshee
Now I'm running 10.10 again with PHC kernel that wont let me complete the bug process.
Thanks for the effort, but I'll stay on 10.10 and let somebody else figure it out.

A month without suspend/resume was more than I could take.
Hope you guys solve it.

Seth,

I finally managed to update the BIOS on this machine to the most recent available as of today.

BIOS was upgraded from version 1.50 to version 2.10.
EC remained at version 1.40.

With this new BIOS behavior is still the same as in the original description.

I also tried all the kernel command line options you suggested, they all have the same behavior, except the last one (acpi_skip_timer_override). With that one, consistently, the system enters suspend, power light blinking, but when I press the power button, it behaves as if I'd just powered on the machine, i.e. suspend state and memory contents are lost and the system reboots afresh.

Let me know if there's something else we can try on this machine.

Waiting for cking's ideas to materialize sounds good, although I'm not sure the kernel is even there when the machine resumes (it looks to me like the kernel "dies" before putting things into suspension), so in this case some way of seeing what the kernel is doing while preparing to suspend could be more useful.

Thanks again for all your help!

Hi,

Are you sure this is now working in Oneiric? I'll test when I can but just wanted to check where/how this got fixed.

Daniel, can you please test if this is actually fixed in Oneiric?

Still not working, with Oneiric and all updates as of 2011-07-12 behavior is still as that described in the original report.

Kernel version string:

Linux 201010-6637 3.0.0-4-generic #5-Ubuntu SMP Fri Jul 8 14:19:59 UTC 2011 i686 i686 i386 GNU/Linux

Daniel: This looks like a good candidate for cking's systemtap scripts. The setup is a little involved (we're hoping to make it easier in the future), but reportedly the results are better than what you get using pm_trace. Instructions are at the following link; let me know if you need any help.

https://wiki.canonical.com/PlatformServices/HardwareEnablement/Documentation/PowerManagement/DebugTools

Hi Seth,

so I ran the pmdebugtools, it didn't get much but it might be of some help.

All the s3-{devices,systemtap,tasks,test,trace}.log files have length zero. The kallsyms.log file is 2.6 MB and I don't know if it's worth posting here. The system seemed to enter suspend but on pressing the power button it doesn't recover, and the fans spin up to top speed. I then rebooted and ran the locatehang program and here's what I got:

Looking for function that matches hash from the Magic Number from the kernel log.
  Magic: 12:64:42 maps to hash: a3d2c
  Hash matches: acpi_hw_write_pm1_control() (address: 0)
The kernel probably wrote to the southbridge the magic to put the machine
into suspend or hibernate and then the machine hung. Generally this means
that the machine did not wake up and get back to the kernel resume successfully
which normally indicates a BIOS issue.

Let me know if this is useful, and/or next steps to follow with this machine.

By the way, I had to run this in Natty because the pmdebug stuff doesn't yet run in Oneiric, so I left the Oneiric task alone, but the behavior is basically the same in either.

We'll have to test a bit more to see whether or not control gets back to the kernel. I made a build that will reboot during resume when that happens. So if you install this build and the machine still hangs on resume then the problem is in the BIOS. I've only produced an i386 build since that's what you were running when you reported the bug; if you need an amd64 build let me know.

http://people.canonical.com/~sforshee/lp708286/linux-2.6.38-10_2.6.38-10.46~lp708286v201107131638/

Seth, thanks for the test kernel!

So if I understand correctly, I should see the machine resuming from suspend and then rebooting?

I tested this many times, and I'm seeing some erratic behavior.

Sometimes I get the "fans spin up, system unresponsive" behavior from the bug description. Behavior A.

Sometimes I get this behavior, which is the same as from comment #27: I boot, then open a terminal and sudo pm-suspend. The machine suspends and the power light starts blinking in orange. I press the power button, power light goes solid green, and the system starts up just as if I'd rebooted it (I see the Toshiba logo, goes through pxe boot attempt, grub, boots into the desktop). Let's call this behavior B

I did 6 test runs with your modified 2.6.38-10 kernel:
test 1,2,3,4 - behavior B
test 5,6 - behavior A

I went back to the original 2.6.38-8 kernel and I got:
test 1 - behavior A
test 2 - behavior B
test 3 - behavior A

This is very strange, I'm not sure the "rebooting" behavior I'm seeing is what should be expected from your "reboot after resume" kernel, and in any case, it doesn't happen reliably every time.

How to proceed from here :(

Your behavior B is what you'd expect to see when you get back to the kernel with the patch applied. I guess we can conclude that at least sometimes you aren't getting back to the kernel, but we can't really tell whether behavior B is due to the reset or something else.

Does that machine have a caps lock LED? If it does, and if it's not already coming on when the machine hangs, I can probably turn it on in the same place where the reset is now to let us know whether or not it's ever making it back to the kernel.

Hi Seth,

yes, it has a caps lock LED built into the key itself.

It looks like it has no working pcspeaker (modprobe pcspkr; beep doesn't produce anything), so I don't think we can use minimodem on this one :(

Okay, assuming I didn't make any mistakes this new build should cause you to hang with the caps lock LED blinking once you get back to the kernel during resume. I haven't had a chance to test it yet though.

http://people.canonical.com/~sforshee/lp708286/linux-2.6.38-10_2.6.38-10.46~lp708286v201107132123/

Hi Seth,

Looks like behavior B (system reboots as if just powered up) was my fault, due to my trigger finger when resuming from suspend. If I press the power button too soon, the system is still entering suspend mode, and during this time, the power button press just causes it to reset and reboot as observed.

Once I realized this, I tested the blinking kernel, but making sure to wait at least 30 seconds after issuing the pm-suspend command. This way, I reliably get behavior A (system unresponsive and fans spin up).

I'm sorry to report that there's no caps lock blinking :( which if I understand correctly means that we don't even get back to the kernel when resuming.

Is it possible to change the way the kernel suspends? maybe it's doing it "wrong" and the bios craps out when trying to resume? I could install the recovery disks that came with the system and test behavior with those, if needed.

Thanks!

Just to be doubly sure, can you go back and test the one that reboots if
we get back to the kernel now that you've determined why you were seeing
reboots before? I think the results will be the same, I just have more
confidence in the reset code than the blinking LED code.

Hi Seth,

I went back to the rebooting kernel. This system is a "bag of hurt" :) I'm seeing erratic behavior, but I was consistent in the testing, waiting for at least 30 seconds before trying to wake up the system.

I can tell you that in *most* attempts (like, 10 out of 12) the system would start afresh after pressing the power button to wake up (behavior B). The other two attempts, I observed behavior "A".

If the kernel is indeed coming back from suspend, might it be worth repeating the diagnostics with systemtap?

Thanks!

It may be worth retrying with system tap to see if you ever get any different results than what you got originally. I'll also try to verify (fix?) the blinking LED code today since it seems like that behavior will really be more informative.

Sorry for going in circles here. I have one more build which is verified to really blink the caps lock LED when control gets back to the kernel. The last one was branching to the wrong label in one spot, causing the LED to be turned on and never turned off. This will give you a clear way to determine whether you're getting back to the kernel.

http://people.canonical.com/~sforshee/lp708286/linux-2.6.38-10_2.6.38-10.46~lp708286v201107191248/

Hi Seth,

Thanks for the new test kernel!

I tested 3 times and I got behavior A all three times. fan spins up, system unresponsive, no blinking led :(

Here's my kernel version string:

Linux version 2.6.38-10-generic (root@tangerine) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #46~lp708286v201107191248 SMP Tue Jul 19 18:16:10 UTC 2011

Having same issue on
ASUS K53E
2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Intel(R) Core(TM) i7-2820QM CPU @ 2.30GHz.

The problem (blank screen/full fan on resume) does not reproduce if I boot in recovery mode - then I can suspend-resume no problem.

When I resume not in suspend but without GUI I see kernel panic in one of the functions called from the "smp_apic_timer_interrupt".

Tell me if I can help more.
Zvi.

Zvisha: Problems with suspend are almost always hardware-specific, so it's extremely unlikely you are experiencing the same problem on your Asus machine that is reported here against a Toshiba. Please open a new bug for your issue by running 'ubuntu-bug linux' from a terminal. Thanks!

Hi Daniel,

I've got one more build for you to try. This one is a bit of a stab in the dark based off of something Colin noticed recently that he theorized could possibly cause problems for some machines. Please give it a try and let me know how it goes. If this one fails we may be out of options.

http://people.canonical.com/~sforshee/lp708286/linux-2.6.38-11.48~lp708286v201108151442/

Hi Seth,

Sorry for the delay in testing this new kernel. Here are the results (not good).

I tried three times with this kernel. Each time I got behavior A (fans spin up, system unresponsive). This system is so erratic that at some point I powered off completely, then back on, and still got the same behavior.

But still, results with the latest test kernel are not encouraging.

Thanks for all your help on this one, let me know if there's something else we can try.

Oh, man, I'm really sorry to report that apparently the hardware is faulty :(

It seemed strange that the behavior was so erratic and, moreover, that it once exhibited the same behavior when cold-booting. So in order to see how the originally-shipped OS behaved, I restored the system to factory configuration using the included recovery discs.

And it turns out that, even under Windows, this particular box fails to resume entirely. I get the same behavior where it enters suspend, and when trying to recover the fans spin up and the system goes unresponsive, requiring poweroff.

It just never occurred to me that the hardware could be defective. It should be the first thing to check.

I offer my sincerest apologies for the time investment, especially to Seth Forshee. Sorry :(

We'll see if it's possible to obtain working hardware and follow up on this.

For now, however, I'd say this bug can be marked Invalid.

Thanks so much for all your help with this, and once again, sorry for the inconvenience :(

No problem. I'll go ahead and close out the bug for now.

Just to follow up on this bug, the Toshiba Tecra R700 exhibiting this problem was sent back to Toshiba for repairs, the mainboard was diagnosed faulty and replaced.

The repaired system suspends and resumes OK and without problems.

So I guess this bug can remain as invalid, and I once again offer apologies for raising a bug for faulty hardware.

Thanks!

This bug is a valid one. I have a fresh Oneiric Install, updated regulary, and it is the first release that cannot resume after suspend on my Dell Vostro laptop. Unfortunatelly, this was a function I used a lot until Oneiric. Now I am not able to, because the laptop freeze and cannot recover.

On Mon, Oct 17, 2011 at 05:46:04PM -0000, marianvasile wrote:
> This bug is a valid one. I have a fresh Oneiric Install, updated
> regulary, and it is the first release that cannot resume after suspend
> on my Dell Vostro laptop. Unfortunatelly, this was a function I used a
> lot until Oneiric. Now I am not able to, because the laptop freeze and
> cannot recover.

marianvasile: This particular bug is invalid because it was caused by a
hardware failure. Suspend/resume problems tend to be very hardware
specific, so it's unlikely any problem you're seeing would be the same
as the problems on the Tecra R700 anyway. You should file a new bug by
running 'ubuntu-bug linux' in a terminal.