wakeup from sleep fails on toshiba nb305

[Joel H.]

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

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.

[Chow Loong Jin (hyperair)]

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

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
success.
/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
snd_page_al...

[Chow Loong Jin (hyperair)]

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

[adriangoodyer (adriangoodyer)]

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.

[Joel H. (jjheik)]

AplayDevices:
 **** 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
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC272 Analog [ALC272 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: joel 1534 F.... pulseaudio
Card0.Amixer.info:
 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)
MachineType: TOSHIBA TOSHIBA NB305
Package: linux (not installed)
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-18-generic root=UUID=f87f3449-19d9-4b29-84df-b12b7b963b3f ro nohz=off
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/zsh
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

[adriangoodyer (adriangoodyer)]

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.

[Anmar Oueja (anmar)]

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

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

[joenix (woutersj)]

I've tried the procedure described in the wiki:
https://wiki.ubuntu.com/DebuggingKernelSuspend
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)]

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

[Jeff (jpound)]

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

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

[Nicolas Roberge (nroberge)]

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

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

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

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

Thanks Damien!

[rhettg (rhettg)]

Worked for me too.

[Chad (chad-schellenger-gmail)]

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

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

[diane-chicoca (diane-chicoca)]

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

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.

[GS Gan (geaksue-gan)]

"nohz=off highress=off" works for me too.

[Lounge Daddy (dan-loungedaddy)]

"nohz=off highres=off"
It seemed to make no change for me.

I have dual boot (w/ win7). Would make any difference?

I'm watching this issue with interest. :)

[sohail (launchpad-taggedtype)]

Confirm that the boot options fix it for me. Ubuntu 10.04 netbook edition, no dual boot.

[sohail (launchpad-taggedtype)]

PS: Thanks to #39 for steps to fix.

[Jasonr (jasonrusmisel)]

A note for Lounge Daddy, I'm dual booting with Win 7 Starter with no issues.

[Carlos F. (carlos366)]

Fails for me with dual boot
Carlos

[Ramon Zarazua Borri (killerfox512)]

Works for me with single boot.

Are there any leads on the screen brightness button issue? Or is there a separate bug for it?

[Carl Liebold (carl-liebold)]

Bug #573287 seems similar/same as this. Need fix...

[jim_charlton (charltn)]

Putting highres=off on the GRUB kernel command line corrupts the audio on the Toshiba NB305. I have posted these same comments to other bug reports about sound and suspend/reawaken problems on the NB305. I am hoping that it will stimulate a resolution of the sleep/suspend/reawaken problem without turning off the highres timers.
***********************
The easiest test to see if the audio is working on the Toshiba NB305 is to go to preferences-> sound and make sure the ubuntu sound theme is selected. Then open a terminal window (accessories->terminal) and when the CLI appears, press and hold the back arrow. You will get a system "bong or ping" indicating an incorrect key entry) just hold it down and after 10 to 20 bongs the sound will distort. It requires 6 seconds before you can get normal sound again. Other programs that stress the sound system will cause this sudden distortion.

The problem can be avoided for many programs by removing pulseaudio (apt-get remove pulseaudio) and reboot. You will lose the volume control applet (and other pulseaudio stuff) but you can use alsamixer to set volumes. Like I said... it is hardly a solution.... but many programs will still work perfectly without pulseaudio installed.

It appears that pulseaudio requires the kernel highres timers in order to work reliably. When you deactivate the timers by putting highres=off on the GRUB kernel command line, it dooms pulseaudio. Or at least this has been my experience. I tried it with a completely clean install, with and without the "nohz=off highres=off". Without those parameters the sound is just fine.

What is really required is a patch to make the machine suspend and reawaken properly when the lid is closed... *without* ... deactivating the highres timers.

As always... take anything I say with a grain of salt. It is just my interpretation of what I observe.

[Lounge Daddy (dan-loungedaddy)]

Well, I realized that because I upgraded to 10.04, I might need to manually upgrade Grub to Grub2. So just to be sure, I did.

And now, voila!, suspend and hibernate works thanks to the "nohz=off highres=off" fix. Of course, the sound was flaking out on me. So I removed pulse.

But thanks for the tips. All is well. :)

[jim_charlton (charltn)]

A solution for maintaining the sound quality while running pulse audio with the "nohz=off highres=off"on the kernel command line has been suggested. See

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/574137

I can confirm that it works 99% of the time. Since using that fix, I have only once had the sound become distorted (on a flash video) and I could not reproduce the effect a few minutes later.

[Sobolosrios (sobolosrios)]

The "fix" that jim_charlton posted works for me as well.

However, this thread's bug remains in that the tickless timers cause problems with suspend/resume on the nb305. All of these other things are work arounds for the fact that we have to turn off the timers.

[jim_charlton (charltn)]

I echo the comments of Sobolosrios. We need to fix the kernel to run tickless with highres timers without the boot and resume problems. I have tried many things and find that using the kernel parameter "nohpet" (don't use the hardware precision event timer) avoids the slow boot problem. But it seems to make the resume problem even worse. The log files (kern.log, etc.) do not give much information after suspend/resume so I cannot tell what is going wrong. The problem may be in the ahci or libata modules (disk driver) as boot will hang for 7 or 8 minutes (if no kernel parameters are used) at the point the root partition is mounted and accessed. Suspend likewise hangs for 7 or 8 minutes and probably at the same point.

[Sobolosrios (sobolosrios)]

I haven't tried tried the parameter nohpet, but I have been messing with this today and don't have a boot problem when I omit "nohz=off highres=off". That is, boot time is about 40 seconds (which is approximately the same as with the arguments).

[Sobolosrios (sobolosrios)]

Have we ruled out that this is not just a problem with the display resuming?

The reason I ask is that there are dozens of pineview netbooks with almost identical hardware that don't have this problem. Maybe we can look at the hardware differences and eliminate that as a cause
.

[Sobolosrios (sobolosrios)]

Please disregard #54. I forgot that I had my BIOS SATA controller set to "compatibility" instead of "ahci".

[jim_charlton (charltn)]

I can add a few observations to the "slow boot" problem on the Toshiba NB305.

If one boots the disk with no kernel parameters then there is a long pause in the boot process of about 6 or 7 minutes after which the system boots and acts normally. This is also true of suspend and resume. There is a 6 or 7 minute hang in the resume, after which the system resumes and runs normally. Why is there the long hangs in the boot and resume processes?

If you boot with the kernel parameter "init=/bin/bash" then the system will boot fairly fast to open a shell. The boot process is stopping just after the file system is mounted and chroot to the file system has occurred. But the file system "init" (upstart) has not yet run. At this point if you check the hard disk parameters by running (as root) "hdparm -tT /dev/sdax", where sdax is the disk partition mounted as / (it is sda5 on my machine), then the disk performance is terrible (938.90 kB/sec and 430.55 kB/sec for instance). If you run init by typing "exec init" then there is a long delay after which gdm starts. If you open a terminal window and test the drive again you will find that it runs at full speed (573.54 MB/sec and 46.58 MB/sec, for instance).

I am pretty sure that the long delays in booting and resuming have to do with the drive problem. But I cannot figure out what is running during the upstart process that "cures" the drive problem. If we knew what it was... we might cure the problem earlier in the boot process and be able to use the machine with highres timers turned on.

All I know, is that running "exec init --verbose" indicates that the upstart jobs mountall, hostname, plymouth, hwclock and ureadahead have all started running before the big delay. One of the later jobs, triggered by event flags set by mountall, is somehow "fixing" the disk after a long delay.

I will report further progress... if any! :-) Any help or suggestions would be welcome.

[Sobolosrios (sobolosrios)]

Thanks Jim. I'm by no means an expert on this, but does this boil down the problem to something that is going on in either /etc/event.d/* or /etc/init.d/* ? The three things that seem to be the crux of the problem are: (1) something in the init process, (2) nohz=off and highres=off is a fix for the problem and (3) this is related to the Toshiba nb305s (as I haven't seen similar problems elsewhere).

Would it be helpful to put debugging statements in the files in event.d and init.d?

[jim_charlton (charltn)]

Progress is being made!
The boot process goes something like this. 1) the BIOS runs GRUB from the MBR on the disk, 2) GRUB loads the kernel image in initrd to a ramdisk filesystem 3) the initramfs "init" script is run, does some housekeeping and mounts the root of the real ubuntu file system, 4) the system chroots to the real disk file system and then runs the upstart process (by executing /sbin/init), 5) upstart runs the jobs described by the scripts in /etc/init; one of the jobs it runs is rc which runs the older init.d tasks. Upstart is event driven rather than being a list of sequential tasks so that upstart jobs may execute simultaneously.

If I boot the NB305 with the kernel parameter "init=/bin/bash", the boot process stops before upstart has run. At that point if I run the command "getty -n -l /bin/bash 38400 /dev/tty2 &" it starts another shell running on tty2 and I can jump there with ctrl/alt/F2. I go back to the boot shell and type "exec init" to start upstart. I immediately go to the tty2 shell (ctrl/alt/F2) and type "initctl list". This gives a list of upstart jobs and their status. Only mountall, plymouth and ureadahaed are started/running. All others are stopped/waiting. Mountall is one of the first processes started and is needed to mount the file system as described in /etc/fstab. Plymouth is a graphical splash screen that is just eye candy (I think). I quote from the ubuntu manual for ureadahead "ureadahead (über-readahead) is used during boot to read files in advance of when they are needed such that they are already in the page cache, improving boot performance".

So I booted the machine and moved ureadahead.conf and plymouth.conf out of /etc/init (I put them in my home directory for safe keeping). I then rebooted with only "ro"on the command line. The boot time went down to about 2 minutes! The resume from suspend went down to about 3 minutes. Ureadahead makes parameter files that the boot process uses. I didn't know how to get rid of those (more reading required) but I just rebooted the machine a few times and BINGO! Boot times went down to 30 seconds!

Not only that... but when I boot with "init=/bin/bash" and check disk performance (before upstart is run) I find the disk is running full speed. Ureadahead parameters appear to have been the cause of the poor disk performance during boot.

The bottom line...... UREADAHEAD appears to be the problem with the slow boot times on the Toshiba NB305. Remove it and boot times (eventually) go back to 30 seconds.

The bad news.... despite early results showing resume from suspend also was faster... I found that after a few reboots, resume from suspend went back to approximately a 6-7 minute delay! :-( So there is still work to be done. But progress is being made. I may eventually file another bug report under ureadahead.

[jim_charlton (charltn)]

Ah .... rats... It always pays to double check everything many times before writing a report.

Ureadahead puts its parameter file "pack" into /var/lib/ureadahead. I confirmed that the pack files were gone after I removed ureadahead.conf and ureadahead-other.conf from /etc/init.

The I did the obvious further test test. I put ureadahead.conf and ureadahead-other.conf back into /etc/init (but left plymouth.conf out) and rebooted. It booted fast. It also recreated the /var/lib/ureadahead/pack file. So I rebooted again. It boots even faster!!! (about 23 seconds). Dang. Ureadahead was not the problem. I booted a couple of times to confirm.

So.... I put plymouth.conf, plymouth-log.conf, plymouth-splash.conf and plymouth-stop.conf back into /etc/init and rebooted. No problem. The boot time remains at 23 seconds. Note that I have only "ro" on the kernel command line. The original ubuntu distribution has also got "quiet splash" there. But I don't want those anyway.

I rebooted several times. If I reboot from a terminal shell issuing the command "reboot" (as root), the boot time is consistently 23 seconds. If I reboot from the gdm desktop using the "restart" menu entry, the boot time is about 48 seconds. I don't know why there is a difference here but I am not so worried about that difference.

Note that I have bootchart running during boot (bootchart.conf in /etc/init).

I am now not sure I want to say what caused the slow boot problem. But removing ureadahead and plymouth and rebooting several times... and then putting them back... appears to have solved the problem. It could be that simply removing any pack files in /var/lib/ureadahead and then rebooting would have also solved the problem. Perhaps someone could test this.

Resume from suspend (lid closed/opened) still takes almost exactly 5 minutes (tested 2 times). So that problem remains.

[Sobolosrios (sobolosrios)]

Thanks Jim, I'll try this out in the morning to test. In particular, I'll try just deleting the pack files in /var/lib/ureadahead first.

[Sobolosrios (sobolosrios)]

It appears that simply removing the pack files in /var/lib/ureadahead isn't enough. I'll try removing ureadahead and plymouth as mentioned and report.

[jim_charlton (charltn)]

Note that I removed both ureadahead.conf and ureadahead-other.conf as well as plymout.conf, plymout-log.conf, plymouth-splash.conf and plymouth-stop.conf. If you can check both boot times and resume times through several reboot cycles after their removal, it may give us some extra info. I can't help but think that the long delay in resume is also disk related. From the /var/log/pm-suspend.log, there is no indication that anything goes wrong in the resume. On lifting the lid, there is a little flash from the drive light and then absolutely nothing happens (the caps lock key, ctrl/alt/F1 and other keys are dead) for a full 5 minutes ... then there is a "click"and everything starts working.

[Sobolosrios (sobolosrios)]

None of jim_charlton's steps seems to work for me. Here is what I have done:

1. rm /var/lib/ureadahead/pack
2. mv /etc/init/ureadahead* ~/
3. mv /etc/init/plymouth* ~/
4. (check to make sure all the conf files related to ureadahead and plymouth were properly moved).
5. Rebooted a few times. Boot times decreased to about 2-3 minutes, but never got down to ~30 seconds (after 4 reboots).
6. mv ~/ureadahead* /etc/init/
7. mv ~/plmouth* /etc/init/
8. Reboot a few times. Boot times go back up to between 7 and 8 minutes.

Just to verify Jim, do you have the SATA controller mode (set in the BIOS) set to achi or compatibility?

[jim_charlton (charltn)]

Yes, the SATA setting is AHCI. I just rebooted and I again get 23 seconds. I will try to attach a copy of dmesg. Note that I have installed bootchart. That installs /etc/init/bootchart.conf. Maybe the placement of another job that runs early in the upstart queue changes the timing of the upstart jobs so that things just work. I have had the same thing happen on another machine where boot would hang unless I changed the order of the upstart jobs. I will also try to upload a copy of the bootchart image that was created on the last startup. It will give you an idea of the timing of all of the boot process. I will also try removing bootchart and see if the the boot delay comes back.

[jim_charlton (charltn)]

Here is dmesg.txt to go with message #65.

[jim_charlton (charltn)]

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

The reboot took 2 minutes 42 seconds.

reboot

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

The reboot took 32 seconds

reboot

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

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

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

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

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?

Thanks!

[jim_charlton (charltn)]

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

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

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

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

[jim_charlton (charltn)]

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

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

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

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

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

Sorry, my email is

sobolosrios <at> gmail <.> com

[jim_charlton (charltn)]

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

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.

[Cameron Matheson (cameron-matheson)]

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

[Adam Smith (scradam)]

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

[Andrew Sorensen (andrew-localcoast)]

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.

[[e-mail] (motoguzzied)]

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?

Thanks,

Ed

[jim_charlton (charltn)]

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
 https://bugs.launchpad.net/bugs/601986.

[Daniele Napolitano (dnax88)]

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

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

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

[David Mazary (dmaz)]

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

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

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

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

@jim_charlton:

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

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

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.

[Leann Ogasawara (leannogasawara)]

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

[Seth Forshee (sforshee)]

Also marking development kernel task as Won't Fix.

[Maximilian Haeussler (maximilianh)]

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.

[Maximilian Haeussler (maximilianh)]

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

[Maximilian Haeussler (maximilianh)]

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.

[Maximilian Haeussler (maximilianh)]

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

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.