Resume after suspend not working - Toshiba Tecra R700

Bug #708286 reported by Daniel Manrique on 2011-01-26
This bug affects 15 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Seth Forshee
Seth Forshee
Seth Forshee

Bug Description

On this system (Toshiba Tecra R700 with i7 processor), suspend exhibits *apparently* normal behavior: the system enters sleep, the power light flashes to indicate sleep.

When pushing the power button to turn back on, the system appears to come back but is unresponsive: display is turned off, CPU fan spins to maximum speed, and the system can't be pinged or accessed through the network.

Hibernate behavior is as follows: the system enters hibernation fine. Upon trying to wake it up, it has the same behavior as when suspending (see above). However, if I re-power-cycle the system, it boots up and de-hibernates as expected, picking up where it left off.

We're using Maverick with latest updates.

- Steps to reproduce
1- Install Maverick, apply latest updates
2- Put the system to sleep
3- Try to wake up by pressing power button

- What I expected to see: the system coming back up where it left off.

- What I saw instead: System unresponsive as described above.

- Did the machine break while going to sleep or waking up?
Observing suspend and hibernate behavior leads us to believe it's an issue while going to sleep.

- Is the problem reproducible?
  Yes, this happens every time.

- Did it work before?

- Do you end up with flashing caps lock or similar?

I followed the steps in DebuggingKernelSuspend and got no useful information (no "hash matches" messages).

We also tried this mainline kernel:
Problem still persists.

This machine is primarily used for testing purposes, so it's available to run any tests that might help with this issue.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: linux-image-2.6.35-25-generic 2.6.35-25.44
Regression: No
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.35-25.44-generic
Uname: Linux 2.6.35-25-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
Architecture: i386
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC259 Analog [ALC259 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
 /dev/snd/controlC0: ubuntu 1765 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
 Card hw:0 'Intel'/'HDA Intel at 0xd4720000 irq 48'
   Mixer name : 'Intel IbexPeak HDMI'
   Components : 'HDA:10ec0269,11790622,00100100 HDA:80862804,11790001,00100000'
   Controls : 21
   Simple ctrls : 10
Date: Wed Jan 26 15:15:02 2011
HibernationDevice: RESUME=UUID=451a47af-4165-4e0b-ac57-c254ec6def57
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
MachineType: TOSHIBA TECRA R700
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-25-generic root=UUID=e3d9760d-21e7-4373-b844-203ea4f8dd14 ro quiet splash initcall_debug no_console_suspend
RelatedPackageVersions: linux-firmware 1.38.3
SourcePackage: linux 08/26/2010
dmi.bios.vendor: TOSHIBA
dmi.bios.version: Version 1.50
dmi.board.asset.tag: 0000000000 Portable PC
dmi.board.vendor: TOSHIBA
dmi.board.version: Version A0
dmi.chassis.asset.tag: 0000000000
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: Version 1.0
dmi.modalias: dmi:bvnTOSHIBA:bvrVersion1.50:bd08/26/2010:svnTOSHIBA:pnTECRAR700:pvrPT319C-006001:rvnTOSHIBA:rnPortablePC:rvrVersionA0:cvnTOSHIBA:ct10:cvrVersion1.0: TECRA R700
dmi.product.version: PT319C-006001
dmi.sys.vendor: TOSHIBA

Daniel Manrique (roadmr) wrote :
description: updated
Daniel Manrique (roadmr) on 2011-01-26
tags: added: blocks-certification
Jeremy Foshee (jeremyfoshee) wrote :

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 . 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.]

tags: added: kernel-suspend
tags: added: kj-triage
Changed in linux (Ubuntu):
status: New → Incomplete
Daniel Manrique (roadmr) wrote :


Thanks so much for looking into this.

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

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!

tags: removed: needs-upstream-testing

Also, the latest SRU kernel in proposed does not alleviate the issue : (linux 2.6.35-27.48)

Daniel Manrique (roadmr) wrote :
Ara Pulido (ara) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → New
Ara Pulido (ara) on 2011-04-08
tags: added: blocks-hwcert
removed: blocks-certification
Ara Pulido (ara) wrote :

Please, assign this bug to the corresponding team.

tags: added: regression-proposed
Changed in linux (Ubuntu Natty):
assignee: nobody → Canonical Platform QA Team (canonical-platform-qa)
importance: Undecided → High
Kate Stewart (kate.stewart) wrote :

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).

Changed in linux (Ubuntu Natty):
status: New → Incomplete
status: Incomplete → Confirmed
milestone: none → ubuntu-11.04
Seth Forshee (sforshee) wrote :

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.

Changed in linux (Ubuntu Natty):
assignee: Canonical Platform QA Team (canonical-platform-qa) → Canonical Kernel Team (canonical-kernel-team)
Daniel Manrique (roadmr) wrote :

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.

Jeremy Foshee (jeremyfoshee) wrote :

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


Changed in linux (Ubuntu Natty):
milestone: ubuntu-11.04 → natty-updates
status: Confirmed → Incomplete
Daniel Manrique (roadmr) wrote :

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.

Seth Forshee (sforshee) wrote :

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.


Victor Tuson Palau (vtuson) wrote :

Daniel - please can you do as suggested by Seth

Daniel Manrique (roadmr) wrote :

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.


Lauge Brixvold (brixvold) wrote :

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.

foxy123 (foxy) wrote :

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

KeithG (grider-4) wrote :

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.


foxy123 (foxy) wrote :

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, but I am not sure it gave me anything. Anyway I am attaching the dmesg.txt

KeithG (grider-4) wrote :

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.

Buddha001 (ndrego) wrote :

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

László Monda (mondalaci) wrote :

Resume from suspend was being broken on my laptop for about half a year. I've just found the thread and written the following script which works like a charm.

gnome-screensaver-command -l
sudo /etc/acpi/ force

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

Ara Pulido (ara) wrote :

Back to confirmed, as the reported replied to the question

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Ara Pulido (ara) wrote :

Back to confirmed

Changed in linux (Ubuntu Natty):
status: Incomplete → Confirmed
Seth Forshee (sforshee) wrote :

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.


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.


Lauge Brixvold (brixvold) wrote :

@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.

Daniel Manrique (roadmr) wrote :


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!

Changed in linux (Ubuntu):
status: Confirmed → New
Brad Figg (brad-figg) on 2011-06-02
Changed in linux (Ubuntu):
status: New → Confirmed
Changed in linux (Ubuntu Oneiric):
status: Confirmed → Fix Released
Daniel Manrique (roadmr) wrote :


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.

Ara Pulido (ara) wrote :

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

Changed in linux (Ubuntu Oneiric):
milestone: natty-updates → none
status: Fix Released → Incomplete
Daniel Manrique (roadmr) wrote :

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

Changed in linux (Ubuntu Oneiric):
status: Incomplete → Confirmed
Seth Forshee (sforshee) wrote :

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.

Changed in linux (Ubuntu Oneiric):
status: Confirmed → Incomplete
Daniel Manrique (roadmr) wrote :

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.

Daniel Manrique (roadmr) wrote :

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.

Seth Forshee (sforshee) on 2011-07-13
Changed in linux (Ubuntu Oneiric):
status: Incomplete → In Progress
Changed in linux (Ubuntu Natty):
status: Confirmed → In Progress
assignee: Canonical Kernel Team (canonical-kernel-team) → Seth Forshee (sforshee)
Changed in linux (Ubuntu Oneiric):
assignee: Canonical Kernel Team (canonical-kernel-team) → Seth Forshee (sforshee)
Seth Forshee (sforshee) wrote :

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.

Changed in linux (Ubuntu Natty):
status: In Progress → Incomplete
Daniel Manrique (roadmr) wrote :

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 :(

Changed in linux (Ubuntu Natty):
status: Incomplete → Confirmed
Seth Forshee (sforshee) wrote :

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.

Daniel Manrique (roadmr) wrote :

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 :(

Seth Forshee (sforshee) wrote :

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.

Changed in linux (Ubuntu Natty):
status: Confirmed → Incomplete
Daniel Manrique (roadmr) wrote :

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.


Changed in linux (Ubuntu Natty):
status: Incomplete → Confirmed

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.

Daniel Manrique (roadmr) wrote :

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?


Seth Forshee (sforshee) wrote :

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.

Seth Forshee (sforshee) wrote :

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.

Changed in linux (Ubuntu Natty):
status: Confirmed → Incomplete
Daniel Manrique (roadmr) wrote :

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

Changed in linux (Ubuntu Natty):
status: Incomplete → Confirmed
Zvisha Shteingart (zvisha) wrote :

Having same issue on
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.

Seth Forshee (sforshee) wrote :

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!

Ara Pulido (ara) on 2011-08-15
tags: added: oneiric
Seth Forshee (sforshee) wrote :

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.

Changed in linux (Ubuntu Natty):
status: Confirmed → Incomplete
Daniel Manrique (roadmr) wrote :

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.

Changed in linux (Ubuntu Natty):
status: Incomplete → Confirmed
Daniel Manrique (roadmr) wrote :

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 :(

Seth Forshee (sforshee) wrote :

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

Changed in linux (Ubuntu Natty):
status: Confirmed → Invalid
Changed in linux (Ubuntu Oneiric):
status: In Progress → Invalid
Daniel Manrique (roadmr) wrote :

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.


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.

Seth Forshee (sforshee) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers