Suspend to ram very slow and not reliable on Toshiba U200

Bug #90771 reported by Lionel Dricot on 2007-03-09
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
linux-source-2.6.20 (Ubuntu)

Bug Description

Binary package hint: linux-image-2.6.20-9-generic

I'm using the following laptop :

Suspend to RAM was not working at all in Edgy due to the following bug :
In fact, suspend was working very well but resume always failed.

fortunatly, the situation is better in Feisty but :

1) It takes a very long time to suspend to ram : exactly 8 min 20 s. The screen turns immediatly black and the computer is iresponsive but, 8min20s later, it will be suspended !

2) Sometimes, resume display for 10 seconds a console with a lot of USB related garbage. Sorry, no camera to show you. It's not always the case.

3) Sometimes, resume is too quick. You can log in and then you will see you GNOME config completely messed, with most panel applets missing and stuffs not working. Just wait 20 seconds and all should be fine.

4) Sometimes, there's no more connection. Sometimes, the connection is just fine, sometimes it's only the wifi that disappear and sometimes even the cable is no more detected by Network-Manager. Rmmod and modprobing does the trick here to get your connection without rebooting.

Linux spoutnik 2.6.20-9-generic #2 SMP Mon Feb 26 03:01:44 UTC 2007 i686 GNU/Linux

Lionel Dricot (ploum) wrote :
Lionel Dricot (ploum) wrote :
Lionel Dricot (ploum) wrote :
Ante Karamatić (ivoks) wrote :

It doesn't resume on my machine :) It just crashes. But, FWIW, it goes to sleep in less than 5 minutes :)

Changed in linux-source-2.6.20:
assignee: nobody → ubuntu-kernel-acpi
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Alejandro R. Mosteo (mosteo) wrote :

Another sample: my toshiba satellite u200-111 takes ~9 minutes to suspend, about 1 minute to come back. At this moment its more time effective to use hibernate, which works ok.

2.6.20-13-generic #2 SMP Sun Mar 25 00:21:25 UTC 2007 i686 GNU/Linux

But I should note that, contrary to what the first poster reported, suspension worked ok for me in a fresh edgy install.

Ante Karamatić (ivoks) wrote :

When on AC power, suspend doesn't work. Screen goes blank and very quickly fans start spinning very fast. When on battery, it suspends after some time (couple of minutes). Screen goes blank, but I think sound is still working and causing problems. I'll do some tests with rmmoding sound modules before sleep.

Resume works. It's quick and stable. Sometimes network doesn't work, but this can be fixed with adding ipw3945 and e100 to MODULES in /etc/default/acpi-support. Maybe rmmoding network modules (which should be by default) doesn't work as expected.

moesto, could you add output of lspci | grep Audio?

Lionel Dricot (ploum) wrote :

here, with the latest kernel in Feisty, suspend seems to work all the time in a very reliable way. Resume works always perfectly and quickly (except a bit of console garbage displayed briefly on the screen).

The only bad point ? Suspend still take 8-9 minutes...

Id2ndR (id2ndr) wrote :

I can suspend in about 5 minutes. And it takes short time to resume (normal time I think). The suspend to ram process is very reliable for me.

Ante Karamatić (ivoks) wrote :

I can confirm that STR works even when on power. It just spins fans to max. Until now I've shut down machine, but this time I've accidentaly left it alone and it was sleeping when I came back. So I did a test, and, yes, it works.

Here are details from syslog which could clarify something (my comments are in []):

Apr 12 11:27:56 satellite gnome-power-manager: (ivoks) Doing nothing because the suspend button has been pressed - [hitting Fn+F3 doesn't suspend computer (worked till now)]
Apr 12 11:28:04 satellite gnome-power-manager: (ivoks) Suspending computer because the DBUS method Suspend() was invoked
Apr 12 11:28:06 satellite NetworkManager: <information>^IGoing to sleep.
... [n-m related stuff]
Apr 12 11:28:09 satellite kernel: [10007.132000] PM: Preparing system for mem sleep
Apr 12 11:28:09 satellite kernel: [10007.132000] Disabling non-boot CPUs ...
Apr 12 11:28:09 satellite kernel: [10007.164000] Breaking affinity for irq 21
Apr 12 11:28:09 satellite kernel: [10007.164000] CPU 1 is now offline
Apr 12 11:28:09 satellite kernel: [10007.164000] SMP alternatives: switching to UP code
Apr 12 11:33:35 satellite kernel: [10007.176000] CPU1 is down - [notice the *big* time difference; this is where suspending is idling and fans spin like mad]
Apr 12 11:33:35 satellite kernel: [10007.176000] Stopping tasks ... done.
... [normal stopping of all devices]

On resume, everything is ok, but there are some issues in syslog:

Apr 12 11:33:35 satellite kernel: [10333.484000] i8042 kbd 00:06: resuming
Apr 12 11:33:35 satellite kernel: [10333.484000] pnp: Failed to activate device 00:06.
Apr 12 11:33:35 satellite kernel: [10333.484000] i8042 aux 00:07: resuming
Apr 12 11:33:35 satellite kernel: [10333.484000] pnp: Failed to activate device 00:07.

Also, sometimes (like after this test), ALPS touchpad doesn't have all the functionality (hor. scroll, different movement speed, etc...). After resume, /proc/acpi/thermal_zone/THRM/temperature shows 56C, while before resume it was 43C. So, processor does run as mad for those 5 minutes while "idling", causing spinning of fans.

Paulo J. S. Silva (pjssilva) wrote :


I have found the problematic module that don't allow suspend to ram to work in the Toshiba U205 S5067 laptop (U200 new brother): it is the sata driver. This laptop has as an Intel ICH7 Family SATA controller that uses the libsata + ata_piix module.

I had a hint that the SATA module could be the problem after ROSS told us that the LFDK CD kernel could suspend to RAM. I confirmed this now after recompiling my distribution kernel (Ubuntu Feisty Fawn, based on kernel 2.6.20) and making the following changes to the kernel configuration (in menuconfig):

1) Compile the following options as builtin (not as module):

Device Drivers -> ATA/ATAPI/MFM/RLL Support -> Include IDE/ATA-2 DISK support
Device Drivers -> ATA/ATAPI/MFM/RLL Support -> genric IDE chipset support

(This is necessary to allow the laptop to access the HD without the SATA driver. Note that the HD works without DMA and hence it is very, very slow, so this is not a real workaround, it is only a way to do the test. Note that with this driver the hd will appear as /dev/hda (and not as /dev/sda). This may make necessary some changes in the GRUB boot options. In Ubuntu no changes to grub are necessary)

2) Turn off (exclude) the ata_piix module:

Device Drivers -> Serial ATA (prod) and Parallel ATA (experimental) drivers -> Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support

After this changes I have recompiled the kernel and rebooted onto the new compiled version.

The laptop is slow due to the DMA-less HD, but I am able to suspend to ram and come back just in LFDK CD.

I will update the bug reports with this information. I may try to debug the driver adding printk to it but I am afraid that the console will go blank before I can see any messages.



Obs: There is a long thread about this bug in the supend mailing list:

Paulo J. S. Silva (pjssilva) wrote :


The bug discussion I mentioned above went to the kernel bug tracker:

Recently, Tejun Heo has posted a patch that solves the problem in my U205-S5067 laptop. Since U205 and U200 are basically the same machine, I believe that the patch should work in U200. However, to make use of it a U200 will have to adapt it as Tejun is using the laptop name to identify the problematic machine (search for U205) in the patch file.

The patch applies cleanly to the gutsy git tree (I am using a patched gutsy kernel right now). Note that you will need the latest, unreleased, tree (2.6.22-7) as the last released tree (2.6.22-6) suffers from a delay in the wake up procedure (as discussed in the end of the bug report).

It would be nice if other people here can try the patch and see if it works.

Finally, be aware that the latest pre-release official kernel (2.6.22-rc5) and, consequentially, the Gutsy git tree can not wake up from suspend to disk in my machine if you have the Ubuntu slash screen enabled. You may want to get rid of the "slash" option in your grub menu configuration to not loose suspend to disk.

Peter Schwenke (bluetoad) wrote :

I have had this problem since I first got my Toshiba Portege M500. Suspend/resume works but the suspend takes 5 minutes. Hibernate has always worked.

I have ported Tejun Heo's patch from
to the Feisty 2.6.20 kernel.

Suspend now works quickly.

Paulo J. S. Silva (pjssilva) wrote :

Just to let you know that Tejun patch was accepted in 2.6.23 kernel and it fixes the problem in many Toshiba laptops, like the U205. Unfortunately, Tejun missed to add the U200 identification string to the accepted patch and the patch was recently re-opened to allow the U200 to be included. Anyhow, it is trivial to change the accepted patch to include U200 too.

See comments on:

Peter, can you attach the diff of your kernel (with the backported patch) to this bug report? It may help someone.

Finally Gutsy kernel will be 2.6.22 and therefore the patch is not there. Any chance to get the patch backported to Gutsy kernel? Should I open a bug report against the Gutsy kernel asking the backport?

Peter Schwenke (bluetoad) wrote :

Paulo, I attached a GIT patch with my comment on 2007-08-10. Looking at the patch I see there it doesn't have the U200 in the patch, however, as you say it is trivial. Are you going to try it?

It has worked well for me. I do get the occasional broken resume but I'm sure that is some other gremlins.

Originally, I blindly applied the patch to the Gutsy kernel and it didn't resume properly. However, I hadn't tried the unpatched kernel first. I'd simply read the advice saying it applies cleanly. I'll have a proper look at it.

Peter Schwenke (bluetoad) wrote :

OK. I've build it again for the upgraded feisty Kernel and tested. I'll upload the
patch again here (since some slight documentation stuff was missing) and include a patch for the U200.

The original patch at should apply cleanly to Gutsy. I looked the code in 2.6.22 and 2.6.23. I'm going to see about upgrading to Gutsy this week and I'll try it.

If anyone would like to avoid the hassle of building the Kernel and testing you can try the packages I have built from I'll leave them there temporarily.

Peter Schwenke (bluetoad) wrote :
Id2ndR (id2ndr) wrote :

Peter Schwenke, I got an U200. I installed 2.6.20-16-ref-generic from your packages (except linux-restricted-modules-2.6.20-16-ref-386_2.6.20.5-16.29_i386.deb that doesn't meet all dependancies).
I have reboot on this new kernel but it still suspend in about 5 minutes. So I'm not sure that the second path have been applied. Is there a way to know it ?

Peter Schwenke (bluetoad) wrote :

Sorry. Looking at the datestamps I copied the second patch to the webserver but not the recompiled packages.
I have since done a "clean" on my Feisty build to get some disk space. The linux restricted modules I built was a cut down version since I don't use ltmodem, ATI or NVideo video.

Anyway, I'm rebuilding and will put the packages up tomorrow.

Peter Schwenke (bluetoad) wrote :

OK. Rebuilt the packages and available at

I have included the M7 since there has been a subsequent patch for it:;a=commitdiff;h=5c08ea019198230a62c601ddf97d0319ae246ad8

I have cleaned up the 3 patches and reattached them. (just getting used to git etc)

I suspect this bug also affects the M4 and M6:

Peter Schwenke (bluetoad) wrote :
Id2ndR (id2ndr) wrote :

Thanks for your work Peter. Unfortunatly this doesn't work yet for me :(.
I deleted old debian package and get the new ones. I removed and purged old ones and then install the new ones.
I rebooted and tried (from both gdm option and while my session was logged).
in both cases, it still toke about 5 minutes to go to sleep. It toke less than 30 seconds to swith the HDD off (it make a sound). The fan speed increased a little after 2 minutes.

Maybe there is an other thing to do with U200, according to

I'm not sure about that, but is the case important to identify the hardware ? There is SATELLITE in the patch wheras I can see that using lshw :
    product: Satellite U200
    vendor: TOSHIBA

Peter Schwenke (bluetoad) wrote :

ld2ndR and I worked this out offline since this bug report is getting messy. I applied the patch referred to in and his computer is now suspending properly.

So going by the dmidecode submitted to this bug by Lionel Dricot and the above comment it appears that the case varies in the Product Name string. I'll also attach ld2ndR's dmidecode output.

Binary packages available at for those wishing to test this without building the kernel

alexnihilo (alexnihilo) wrote :


I'm on Feisty with a Toh; U200-163 and I'm not sure to understand what I have to do to fix the problem without patching the kernel. My kernel number is should I install ALL the 4 packages (.deb) available at ? Then should I refuse next update of the kernel ? I prefer to be sure before mashing up everything. Thank you for your work and your understanding!

alexnihilo a écrit :
> Hi,
> I'm on Feisty with a Toh; U200-163 and I'm not sure to understand what I
> have to do to fix the problem without patching the kernel. My kernel
> number is should I install ALL the 4 packages (.deb)
> available at ?
> Then should I refuse next
> update of the kernel ? I prefer to be sure before mashing up
> everything. Thank you for your work and your understanding
I don't know about that. Maybe this patch will be include in kernel's
officials branches and everybody will get suspend works with Satellite.

alexnihilo (alexnihilo) wrote :

Ok, thanks a lot for your answer !

alexnihilo (alexnihilo) wrote :

Great, congratulations ! it works very well. I just had to install the packages in a special order to avoid problem with dependencies:

I hope this patch will be include in the next kernel ! thx !

Id2ndR (id2ndr) wrote :

patches are OK. Now we need to be sure that it'll be include in official kernel releases.

Changed in linux-source-2.6.20:
status: Confirmed → In Progress
Lionel Dricot (ploum) wrote :

I still have the problem in Gutsy. Has someone tested in Hardy ?

Peter Schwenke (bluetoad) wrote :

You can read about what has happened in the Gutsy version of this bug:

There is a link there for people to test against a patched Gutsy version.

The laptops discovered there have been submitted upstream and are finding their way into Hardy via 2.6.24 kernel rebases.

Hi Everyone,

Peter, again thank you so much for all your efforts to get this upstream. It's very much appreciated from the kernel team. It would seem that this bug should be resolved with the Hardy Alpha release. For those interested, the Hardy Heron 8.04 Alpha series is currently under development and contains an updated version of the kernel. It would be helpful if you could test the latest Hardy Alpha release: . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. We'll keep this report open against the actively developed kernel but against 2.6.20 this will be closed. Thanks.

Changed in linux:
status: New → Incomplete
Changed in linux-source-2.6.20:
status: In Progress → Won't Fix
Lionel Dricot (ploum) wrote :

On Hardy Alpha 5, suspend to ram is pretty quick and seems to be reliable on my toshiba u200-163.

For me, this solves this long standing bug (yeepee :-) )

On Wed, 12 Mar 2008 19:14:52 -0000
Lionel Dricot <email address hidden> wrote:

> On Hardy Alpha 5, suspend to ram is pretty quick and seems to be
> reliable on my toshiba u200-163.
> For me, this solves this long standing bug (yeepee :-) )

I can confirm this.

Marking this as "Fix Released" against Hardy as the original bug reporter has confirmed this is resolved. Thanks.

Changed in linux:
status: Incomplete → Fix Released
Curtis Hovey (sinzui) on 2012-04-09
Changed in linux-source-2.6.20 (Ubuntu):
assignee: Registry Administrators (registry) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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