wakeup from sleep fails on toshiba nb305

Bug #508516 reported by Joel H. on 2010-01-16
This bug affects 42 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
linux (Fedora)
linux (Ubuntu)
Seth Forshee
Nominated for Dapper by powerbuddy
Nominated for Hardy by powerbuddy
Nominated for Jaunty by powerbuddy
Nominated for Karmic by powerbuddy
Nominated for Lucid by Carl Liebold
Nominated for Maverick by Carl Liebold
Seth Forshee
linux (openSUSE)

Bug Description

I installed Ubuntu 9.10 standard desktop edition on the Toshiba NB305 (Atom powered netbook). Most features work, however the machine will not wake from sleep.

Steps to reproduce:

1) Install Ubuntu 9.10 on the Toshiba NB305
2) Put the newly installed system to sleep either by the user menu or closing the lid.
3) The machine will not wake up.

Power is restored, the hard drive and fan spin up, various lights light up but the machine's screen does not reactivate, it remains unlit.

I am unsure whether to file a related bug about this or consider it the same problem-- restoring from suspend to disk (hibernate) also does not work, it hangs at the "Please wait..." screen with the Ubuntu logo.

== Release Notes ==
See comment #94

adriangoodyer (adriangoodyer) wrote :

Thanks for taking the time to report this bug and making Ubuntu better!
I have assigned this bug to pm-utils package instead of gnome-power-manager as I believe from what you have described that the system recognizes that it needs to boot but is unable to do so.

affects: ubuntu → pm-utils (Ubuntu)
Changed in pm-utils (Ubuntu):
status: New → Incomplete

Could you attach your /var/log/pm-suspend.log after a failed suspend and
hibernate to this bug please?

Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

Joel H. (jjheik) wrote :
Download full text (5.2 KiB)

I no longer run the stock Ubuntu kernel, I have found tuxonice to provide working suspend-to-disk functionality. Since this module doesn't involve suspend-to-ram and the behaviour for suspend-to-ram continues to be the same, I will post the log from suspend-to ram anyway. If this is not useful, I will reinstall stock ubuntu on this machine to generate the required logs.

Most recent entry (for a suspend) in /var/log/pm-suspend.log:

Mon Jan 25 14:33:30 EST 2010: Running hooks for suspend.
/usr/lib/pm-utils/sleep.d/000record suspend suspend: success.
/usr/lib/pm-utils/sleep.d/00auto-quirk suspend suspend: Adding quirks from HAL: --quirk-dpms-on --quirk-dpms-suspend --quirk-vbe-post --quirk-vbemode-restore --quirk-vbestate-restore --quirk-vga-mode-3
/usr/lib/pm-utils/sleep.d/00logging suspend suspend: Linux freyja 2.6.31-18-generic #54+tuxonice1-Ubuntu SMP Thu Dec 17 00:54:35 UTC 2009 i686 GNU/Linux
Module Size Used by
omnibook 49588 0
nls_iso8859_1 3740 0
nls_cp437 5372 0
vfat 10716 0
fat 51452 1 vfat
aes_i586 8124 2
aes_generic 27484 1 aes_i586
hidp 14268 0
binfmt_misc 8356 1
ppdev 6688 0
bridge 47952 0
stp 2272 1 bridge
bnep 12060 2
btusb 11856 2
snd_hda_codec_realtek 203328 1
snd_hda_intel 26920 2
snd_hda_codec 75708 2 snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 7200 1 snd_hda_codec
snd_pcm_oss 37920 0
joydev 10240 0
snd_mixer_oss 16028 1 snd_pcm_oss
arc4 1660 2
ecb 2524 2
snd_pcm 75296 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_seq_dummy 2656 0
iptable_filter 3100 0
ip_tables 11692 1 iptable_filter
snd_seq_oss 28576 0
ath9k 84612 0
ath9k_common 3100 1 ath9k
x_tables 16544 1 ip_tables
snd_seq_midi 6432 0
mac80211 211276 2 ath9k,ath9k_common
snd_rawmidi 22208 1 snd_seq_midi
ath9k_hw 229520 2 ath9k,ath9k_common
ath 8924 2 ath9k,ath9k_hw
snd_seq_midi_event 6940 2 snd_seq_oss,snd_seq_midi
snd_seq 50224 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
snd_timer 22276 2 snd_pcm,snd_seq
snd_seq_device 6920 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
cfg80211 131784 4 ath9k,ath9k_common,mac80211,ath
uvcvideo 59080 0
snd 59204 16 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
videodev 36736 1 uvcvideo
psmouse 56500 0
v4l1_compat 14496 2 uvcvideo,videodev
led_class 4096 1 ath9k
lp 8964 0
serio_raw 5280 0
soundcore 7264 1 snd


Chow Loong Jin (hyperair) wrote :

Redirecting to linux. pm-utils has successfully suspended the computer, but kernel never wakes up.

affects: pm-utils (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Incomplete → New
adriangoodyer (adriangoodyer) wrote :

Please run the following command which will attach necessary information:

apport-collect BUGNUMBER

where BUGNUMBER is the number of the bug you've reported above.

Bear in mind that you may need to install the python-launchpadlib package from the universe repository with 'sudo apt-get install python-launchpadlib'. Additionally, when prompted to give apport-collect permissions for Launchpad you will need to give it at least the ability to "Change Non-Private" data as it will be adding information to your bug report.

Changed in linux (Ubuntu):
status: New → Incomplete

 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC272 Analog [ALC272 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
Architecture: i386
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC272 Analog [ALC272 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
 /dev/snd/controlC0: joel 1534 F.... pulseaudio
 Card hw:0 'Intel'/'HDA Intel at 0x40100000 irq 22'
   Mixer name : 'Realtek ALC272'
   Components : 'HDA:10ec0272,1179ff30,00100001'
   Controls : 17
   Simple ctrls : 11
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=954a2330-6369-4d75-b0d2-8ee9f2484068
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
Package: linux (not installed)
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-18-generic root=UUID=f87f3449-19d9-4b29-84df-b12b7b963b3f ro nohz=off
ProcVersionSignature: Ubuntu 2.6.31-18.54+tuxonice1-generic
RelatedPackageVersions: linux-firmware 1.25
Uname: Linux 2.6.31-18-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 11/20/2009
dmi.bios.vendor: TOSHIBA
dmi.bios.version: V1.10
dmi.board.name: NPVAA
dmi.board.vendor: TOSHIBA
dmi.board.version: 1.00
dmi.chassis.asset.tag: *
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnTOSHIBA:bvrV1.10:bd11/20/2009:svnTOSHIBA:pnTOSHIBANB305:pvrPLL3AC-00F014:rvnTOSHIBA:rnNPVAA:rvr1.00:cvnTOSHIBA:ct10:cvrN/A:
dmi.product.name: TOSHIBA NB305
dmi.product.version: PLL3AC-00F014
dmi.sys.vendor: TOSHIBA

Joel H. (jjheik) wrote : CRDA.txt
Joel H. (jjheik) wrote : Lspci.txt
Joel H. (jjheik) wrote : Lsusb.txt
Joel H. (jjheik) wrote : RfKill.txt
Joel H. (jjheik) wrote : UdevDb.txt
Joel H. (jjheik) wrote : UdevLog.txt
Changed in linux (Ubuntu):
status: Incomplete → New
tags: added: apport-collected
adriangoodyer (adriangoodyer) wrote :

Thanks for running the command and collecting the relevant information. This bug has now enough information provided for a developer to begin work and is now in the correct package so I'm going to mark it as confirmed again and let them handle it from here.

Changed in linux (Ubuntu):
status: New → Confirmed
Anmar Oueja (anmar) wrote :

I suggest you try Lucid Alpha2. Some work went into it to support the NB205 and chances are it will work for the NB305 since it might be a BIOS issue.

Joel H. (jjheik) wrote :

Tested with Lucid Alpha 2 Desktop i386. Suspend fails in the same way as on 9.10.

joenix (woutersj) wrote :

I've tried the procedure described in the wiki:
The first try gave:
> Magic number: 14:273:189
> acpi device:1b: hash matches
From lspci I get that
"00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)"
I then removed all sound drivers but still could not recover from suspend. Now there was only this in the dmesg output:
> Magic number: 14:926:340

When trying to resume, the hard disk led blinks and the wireless led turns on and the system does not respond to Alt-PrtSc-REISUB.

Are there other debug methods to try?

joenix (woutersj) wrote :

I've tried a BIOS update to version 1.30, no improvement.

Jeff (jpound) wrote :

This bug (or the cause of this bug) can be reproduced without invoking sleep or hibernate. The problem is simply the switch to (re)enable the screen.

1. Boot the nb305 into UNR.
2. Push function+f5 (display toggle).

The display will turn black, and will not switch back on even if you try toggling back.

(If this should be filed as a separate bug let me know, or go ahead and file one).

Joel H. (jjheik) wrote :

I can confirm this with 9.10 Desktop x86 release. Screen brightness is also not adjustable.

Nicolas Roberge (nroberge) wrote :

I have this issue. I noticed the same issue with waking up the NB305. But, it seems an issue with reactivating the screen. I can reproduce this issue only by disabling and reenabling the screen like Jeff said.

Screen brightness isn't ajustable with FN + F6 and FN + F7.

Matthew (imjustmatthew) wrote :

The sleep issue and display issue may be slightly different, the hardware acts slightly differently in the different cases. When waking from sleep the main board power comes up, but wifi and display don't. When changing the display it get's stuck off, but wifi doesn't drop out.

This issue remains present on 10.04 beta

Damien Tougas (damien-tougas) wrote :

I have been having the same problems with waking from sleep on my NB305 with Fedora 12. I added the following boot kernel parameters:

    nomodeset nohz=off highres=off

Now my system boots much faster and suspend/resume works perfectly. Brightness/contrast buttons still don't work though.

Sobolosrios (sobolosrios) wrote :

I just wanted to chime in and mentions that Damien's fix works for me as well on my nb305.

Thanks Damien!

rhettg (rhettg) wrote :

Worked for me too.

Chad (chad-schellenger-gmail) wrote :

Suspend works for me on the nb305 when "nohz=off highres=off" are passed as parameters. Including nomodeset caused X to fail to start.

Damien Tougas (damien-tougas) wrote :

Chad: I was having problems getting X to start reliably (sporadically) until I added the "nomodeset" option.

diane-chicoca (diane-chicoca) wrote :

Thx Damien. I did this and suspend works for me on my Toshiba nb305... so far.

1) sudo gedit /etc/default/grub
2) Change: GRUB_CMDLINE_LINUX_DEFAULT="splash nohz=off highres=off"
3) sudo update-grub (I don't know if I had to do this.)
4) restart
5) after reboot, close the lid, wait for orange slow-blinking light
6) open lid, press power button once, enter password, click on unlock
7) It works.

I have ubunto 9.10 netbook remix only (no windows), one partition. When I used the nomodeset option it woke up, but it wouldn't start programs, had to force it off.

Jasonr (jasonrusmisel) wrote :

I ran into a problem with installing lucid (10.04) on my Toshiba nb305. After a clean install, it was hanging at boot unable to find the boot drive in grub. As a last ditch hope I added "nohz=off highres=off" to the linux boot line and it now boots up.

I've modified /etc/default/grub and done an update-grub to make the change permanent and it seems to be working fine now. this has also addressed the wake up from sleep issue.

I'll raise a separate bug for Lucid but I thought it might add something to this investigation.

26 comments hidden view all 106 comments
jim_charlton (charltn) wrote :

Yes. I was correct. I did (as root):
apt-get remove bootchart

The reboot took 2 minutes 42 seconds.


The reboot took 7 minutes 34 seconds (longer, I presume, because ureadahead has installed a pack file after profiling on the first boot).

apt-get install bootchart
(check to make sure there are not pack files in /var/lib/ureadahead (there were not)

The reboot took 32 seconds


The reboot took 23 seconds. (shorter as ureadahead has profiled on the first boot and the pack file now actually works to shorten boot time).

So installing bootchart is the secret! It must subtly change the timing of the execution of upstart jobs such that some jobs complete in time for the next job to start. Without it.... something is starting too soon and causing the long delay.

So what happens in "resume"? Does it also use upstart? I need to do some reading. Maybe the solution to the resume delay is something as simple as changing the order/timing of the restarting of system tasks.

In the meantime... the slow boot can be (apparently) be solved by installing bootchart.

jim_charlton (charltn) wrote :

After installing bootchart, resume (lid close/open) still takes 5 minutes. But.... pm-hibernate (as root), although it takes a few seconds to save the image to disk, resumes on pushing the power button in about 12.5 seconds!

So.... One can use pm-hibernate to save your running programs and then resume them by just hitting the power button.

Can the lid close/open be programmed to use pm-hibernate instead of pm-suspend? I think that /etc/acpi/lid.sh is what starts the suspend/resume but I can't really follow the script to the point where it calls pm-suspend. Sigh.... more reading! :-)

Sobolosrios (sobolosrios) wrote :

I can confirm that the installation of bootchart (sudo apt-get bootchart) speeds the boot from several minutes to about 30 seconds (it takes 23 seconds to the start of the pinwheel.)

Thanks for all of your work Jim. I'll take a look at the lid.sh script. Tejigging that script would be a bit of hack, but right now I'll take anything to get some battery life back.

Thanks again, Jim.

jim_charlton (charltn) wrote :

To use hibernate instead of suspend on lid close is easier than I thought. Use
gconf-editor (I did this as a regular user)

Go to apps->gnome-power-manager->buttons and change lid_ac and lid_battery to hibernate instead of suspend.

I then tried closing the lid without the ac power attached. When I opened again, I had to press the power button and then the system rebooted and tried to resume. But the x-display did not start properly. So I shut down and tired again with the power attached. This time it hibernated and when I opened the lid, it automatically resumed. The resume takes only about 12 seconds but the hibernate on closing the lid takes about a minute. I tired again with the ac power disconnected. This time I had to press the button to get it to resume but it resumed just fine.

So I think this works and is a pretty good work-around for the failure to suspend to ram. It is just a bit slow to write the image to disk... But typically we don't really care about an extra minute to shut down. We just want it to restart fast with all of our programs running. I have to admit that I did not try it with a bunch of programs running. That should be checked.

I may still work on getting suspend to ram (s2ram) and resume to work.. but for now... I am happy with how it works.

Sobolosrios (sobolosrios) wrote :

Hibernate doesn't seem to work at all for me. In particular, it takes at least 40 minutes to reload the cached data from swap. It might take longer, but eventually I did a hard reset, figuring that something else must be going on. Is it possible that you made some other adjustments that effected the resume-from-hibernate time?


jim_charlton (charltn) wrote :

Shoot and dang... and many other expletives.

Of course. you are perfectly correct. I had forgotten that I had installed uswsusp. I thought that it was insignificant as I could see no difference earlier without bootchart. But now I am not sure. When I remove uswsusp (apt-get remove uswsusp), my machine will not even hibernate at all. I did not try suspend. When I reinstall uswsusp then the hibernate and resume work just fine. Please try installing this piece of software and see if your machine will also hibernate and resume.

uswsusp is a replacement for suspend. But I did not think that it had actually been activated as I could see no mention of it in the scripts that run suspend and hibernate. But I guess it is installed and activated somehow. It also gets installed in the initram image so it probably affects the resume process as well. I am pretty sure that I did not install any scripts that launch uswsusp, but to be sure I need someone else to try the installation and then the hibernate resuem (pm-hibernate and after the machine hibernates.... push the power button).

I need to look into this further... of course... more work!!! :-) But progress is being made... slowly! :-)

Sobolosrios (sobolosrios) wrote :

I think there must be at least one more thing to get this to work. I installed uswsusp, but I still can't get it to hibernate, either through Gnome, or by calling pm-hibernate on its own. Any further suggestions?

jim_charlton (charltn) wrote :

Can you give me more information on what happens when you use "sudo pm-hibernate"? On My machine, it jumps to a terminal window where it says "Looking for splash system... none". Then there are 5 lines of output from s2disk about snapshotting the system and storing the image. On reboot it boots like normal except that it loads a resume image and starts up again.

Usually the image storing and reloading are pretty fast... although sometimes there is a slight delay part way through storing the image... and/or restoring the image.

If I run "sudo s2disk", it hibernates to disk as previously. Try that and let me know what happens.

Hmmmm... Occasionally I find that the xserver dies with a flickering screen and a message saying that the X will restart in low resolution. Then I get the login screen. This seems to only happen after a resume from hibernate. So maybe there are additional problems. Sigh....

I will send you a list of my installed programs. If you could compare it to yours and let me know what I have (or don't have) that you don't have (or have) ... maybe we can make some progress. See the following posting.

jim_charlton (charltn) wrote :

Here is an attachment with a list of my installed software.

jim_charlton (charltn) wrote :

Hmmmm... I added the file /etc/pm/config.d/00sleep_module after I installed uswusp. The file contains the line "SLEEP_MODULE=uswsusp". I cannot recall why I did this (possibly because of info in http://www.ubuntugeek.com/fix-for-suspend-and-hibernation-problem-for-laptops.html).

Maybe this is why your hibernate does not work. When I commented out that line in the file, my machine refused to hibernate and froze up so that I had to hard reboot. Sorry about forgetting that. Too many things to remember! :-)

jim_charlton (charltn) wrote :

I recompiled the 2.6.32 kernel with ACPI debugging turned on. The newly compiled kernel boots fine with bootchart installed. Hibernate also works with uswsusp installed and the /etc/pm/config.d/00sleep_module file installed as in message #76. But no matter what debug level/layer I set for ACPI, I can see nothing in the logs that hint at why there is still a 5 minute delay in resuming after pm-suspend.

Sobolosrios (sobolosrios) wrote :

Adding the 00sleep_module file as above fixed the hibernate issue.
I need to do some research on how to get the lid to trigger hibernate instead of sleep as changing the entry in gconf-editor as described still seems to be triggering suspend to ram.

After this is over, I will buy you the beverage of your choice via paypal, Jim. You've been a lifesaver.

jim_charlton (charltn) wrote :

Are you sure that you ran gconf-editor as "user" and not as "root"? Each user has its own gconf settings and if you log in as "user" then the lid signals will be processed by the user's gconf parameters. If you set those parameters from a root shell or by using "sudo gconf-editor", then you will set the parameters for root and when you close the lid it will still suspend, as user still has the suspend parameter.

If you can confirm that this is not an issue, then I can check other possible problems.

Sobolosrios (sobolosrios) wrote :

I believe that I had run it as "user," but I must have messed it up somehow. I have since gotten it to work. Thanks for your help. Do you paypal? If so, you can email me from the address that you use for paypal and I'll buy you "a drink," as promised.

Sobolosrios (sobolosrios) wrote :

Sorry, my email is

sobolosrios <at> gmail <.> com

jim_charlton (charltn) wrote :

Thanks for the kind offer of the beverage. :-) No reward is required. I work on this stuff for amusement. :-)

I was wondering why installing bootchart solved the slow boot and slow resume from hibernate. I got the sources for bootchart. There is a script installed in the initramfs that runs under init-top called "bootchart". It sets up a mini file system in /dev, chroots to it, and starts a program called "collector" which is a compiled C program that collects statistics on the boot process. (if you want to compile collector from sources (bootchart-collector.c), you need to use the gcc parameter -mtune=i386 to get a binary like the one that is installed by "apt-get install bootchart").

To make a long story short, launching of "collector" cures the slow boot. I slowly stripped all of the code out of "collector" until there was nothing left but an infinite "for loop". "for (;;) { ; }" . That alone was enough to get the boot process to run at top speed. Once the machine boots, one can see that the "collector" process is taking about 98% of the CPU cycles of at least one of the CPUs, and sometimes both of them. I just kill the process to not stress the machine.

It appears that "collector" just saturates the CPUs, and this alone is enough to cure the slow boot problem. Why??? I don't know. I tried many other short C programs with various looping structures, but only those that run pretty well flat out, are able to cure the slow boot process.

jim_charlton (charltn) wrote :

More info... I boot without bootchart installed and with the kernel parameters "rw init=/bin/bash". On getting the shell prompt, running "hdparm -t /dev/sda5" gives about 500 kB/sec for buffered disk reads. If I start a c program that is an infinite loop (while (1) {;}), then hdparm gives about 70 MB/sec for buffered disk reads. Killing the C program kills the disk performance. If I run "top" while the C program is running and press "1" (the number one), then I can see that the infinite loop C program is saturating CPU-1 (100%). CPU-2 is just idling.

Why is it that running a program that uses 100% of one of the two CPUs brings disk performance up to normal? And killing that process drops the disk performance back to zilch???

Even after the upstart scripts have run ("exec init" from the shell above), the drive performance is much better while running the C program that saturates one CPU (69 MB/sec) than without that program running (42 MB/sec). This is reproducible.

There is something wrong with the way the disk driver works on this machine (NB305). It results in the slow boot and hibernate/suspend problems. Why saturating one CPU "cures" the problem is a mystery to me.

I upgraded my netbook to Maverick and this is still an issue.

Adam Smith (scradam) wrote :

nomodeset nohz=off highres=off solved all my problems a month ago, but I just upgraded to Maverick and it regressed - my boot time is still good but suspend no longer works. I just raised this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/656236

The only solution I am aware of is to set the CPU frequency to "Always Low" in the bios, however this makes things very slow.

I ran the lines per #39:
1) sudo gedit /etc/default/grub
2) Change: GRUB_CMDLINE_LINUX_DEFAULT="splash nohz=off highres=off"

and it will wake from sleep now, but reliably takes 7-10 minutes to boot.

I don't need wake from sleep as much as I need the NB305 to boot fast. I didn't save the original line ;( (my bad).
Can any one tell me how to put the line back to default so the machine will boot?



jim_charlton (charltn) wrote :

What version of Ubuntu are you running? Give us the output of 'uname -r' and also 'cat /etc/lsb-release'. Not all Ubuntu versions react the same on the Toshiba NB305. You can see other posts on my stuggles with this in

Daniele Napolitano (dnax88) wrote :

In my Toshiba NB305, with Ubuntu Netbook Edition 10.10, kernel 2.6.36 and xorg-edgers PPA, suspend-to-disk and suspend-to-ram works fine.

Boot time is ok, less then 30 seconds.

No GRUB boot line edits.

David Mazary (dmaz) wrote :
David Mazary (dmaz) wrote :

This is still unresolved in the latest 2.6.37 kernel in Natty, and in fact regresses in that wake from sleep fails even with tickless mode disabled in the kernel, which had fixed resume in the kernels of Ubuntu 10.04 and 10.10 as seen in previous comments to this bug.

I've gzipped and attached the 'results.log' generated from 'sudo fwts method' and 'sudo fwts syntaxcheck'. The output of the first reveals errors in _WAK and the second shows 2 errors in the DSDT syntax.

Seth Forshee (sforshee) on 2011-02-16
Changed in linux (Ubuntu):
assignee: nobody → Seth Forshee (sforshee)
status: Confirmed → In Progress
Seth Forshee (sforshee) wrote :

@David, you need to specify both nohz=off and highres=off to work around this bug.

David Mazary (dmaz) wrote :

Sorry, I should have specified that I was using both parameters before. Setting those parameters with the latest 2.6.38 kernel in Natty does again work around the issue, which had regressed under the 2.6.37 kernel.

Seth Forshee (sforshee) wrote :

This is a BIOS bug that cannot reasonably be fixed in the kernel.

I propose adding the following to the natty release notes:

Toshiba NB305 hangs for 5 minutes after suspend. Workaround: specify "nohz=off highres=off" as kernel parameters at boot.

jim_charlton (charltn) wrote :

I have looked into the issues on the NB305 in some detail. Why do you think that the problem is in the BIOS and that it cannot be fixed in the kernel? MS Windows will boot fine using AHCI mode.

I am running Ubuntu 10.10 Maverick 22.6.35-27-generic in AHCI mode and I boot by tapping the left shift key during boot. Every time the disk light ceases to flicker, tap the key. Hibernate works fine but needs key tapping to restore the image.

I think that the problem is with the disk driver. If you set the disk to compatibility mode in the BIOS the problems go away (although I have not checked this recently and it is reported that suspend and hibernate still have problems in compatibility mode). "compatibility" mode will not work for the windows partition.

Using nohz=off highres=off changes your machine so that the kernel does not use "tickless" mode. This makes the machine less efficient making it run hotter and shortening the time it will run on the battery. It also screws up pulse audio some of the time.

Like others who have looked at this, I believe the problem is with the AHCI disk driver and the master scheduler. The driver does not generate interrupts to keep it running. Tapping the left shift key generates a keyboard interrupt which kicks the scheduler back into action and puts the driver back into the queue until it gets rolled out again. I believe that is why you have to keep tapping the key. I am not a kernel expert though... so this may be all just idle speculation and incorrect terminology.

Consistent with this is the fact that installing bootchart on earlier kernel version would completely cure the problem. And I found that any program that would saturate one of the CPUs during boot would also cure the problem. I think it just keeps the scheduler actively rolling the disk driver back in by some magic.

It is a pity that someone who actually knows how the kernel magic works, cannot find time to look at this.

David Mazary (dmaz) wrote :

The I/O timeouts you mention are caused by the poor BIOS. Intel's BITS reports a maximum SMI latency of 418 microseconds for my NB305, which is very high.

Running the kernel with nohz=off and highres=off does reduce power efficiency, but not significantly; I can still achieve 9 hours of battery life. These settings no longer cause Pulseaudio to have any problems, in Natty.

Seth Forshee (sforshee) wrote :


The original bug report is referencing suspend-to-RAM (S3), not hibernate. Issues with hibernate need to be the topic of a separate bug report.

The hang during resume from S3 happen during a callback to the BIOS via SMI during execution of the ACPI _WAK control method. The SMI handler appears to be waiting for an interrupt from the HPET timer. When the kernel is in tickless mode or is using highres timers the HPET doesn't have an event pending when the _WAK method executes, and the SMI handler doesn't return control back to the kernel until the HPET counter wraps around back to the value previously programmed into the match register, which takes 5 minutes.

With nohz/highres disabled, the HPET is in periodic mode during resume from S3 and thus is generating interrupts on a periodic basis, which makes the delay in the SMI handler minimal. Another interesting data point is that if you boot with nohpet on the command line, the machine never finishes resume from S3.

This is pretty clearly an issue being caused by the BIOS since it's happening in an SMI handler. The nohz=off highres=off will increase power consumption to some degree by not letting the CPU idle as much and not allowing it to hit deeper C-states, but as David notes the effect isn't that significant and imho is better than the alternative. Coincidentally keeping the CPU out of deeper C-states fixes the performance problems on these machines, as these occur anytime the CPU is allowed to idle deeper than C1 (you can demonstrate this by passing intel_idle.max_cstate=1, but again this issue isn't really the topic of this bug).

jim_charlton (charltn) wrote :

Response to Seth: (#97)

I take back what I said about someone looking at this who understands kernel magic! Seth obviously has a pretty good handle on this. Perhaps Toshiba will see fit to update their BIOS. That would be nice.

I am not sure how Windows manages to boot with no problems.

Seth Forshee (sforshee) wrote :

I've been told that Windows doesn't support tickless operation, although I don't know that from first-hand experience. Those parameters essentially disable tickless and make the kernel fall back to using the hpet for ticks, so if that's what Windows does then it probably does work fine.

Changed in linux (Ubuntu Natty):
importance: Undecided → High

Based on Seth's analysis, I'm marking this as Won't Fix against the kernel.

Changed in linux (Ubuntu Natty):
status: In Progress → Won't Fix
description: updated
Seth Forshee (sforshee) wrote :

Also marking development kernel task as Won't Fix.

Changed in linux (Ubuntu):
status: In Progress → Won't Fix
Seth Forshee (sforshee) on 2011-04-25
Changed in ubuntu-release-notes:
status: New → Fix Released

This is still the same in Oneiric but there is no note anymore in the release notes. Disabling nohz/highres does improve boot speed but standby does not work.

Hibernate works in Oneiric so I switched to hibernate as default in the Unity config tool.

Need to correct the two previous posts: Kernel 3.0.0-14, Disabling nohz/highres does not change anything. Suspend does not work, Hibernate works out of the box. Screen brightness keys work. Hitting shifting during return from suspend does not change anything, the caps-lock light, for instance, does not change when I hit caps lock.

Does not work with uswsusp's s2ram either.

Sorry, correction: fast booting and resume from suspend works in Onreiric if GRUB_CMDLINE_LINUX_DEFAULT is set to "nohz=off highres=off", as pointed out previously. I had other options activated that prevented it from working.

Should this be be part of the release notes of Onreiric, too?

jim_charlton (charltn) wrote :

It is my experience that the NB305 runs considerably hotter and uses more power (shorter run time on battery) if run with nohz= off highres=off. I just prefer to tap the left shift key during boot and then only use hibernate instead of suspend. It is too bad that Toshiba doesn't issue an update of the bios to generate the proper interrupts for tickless kernels.

Displaying first 40 and last 40 comments. View all 106 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers