hibernate fails when not on AC power on HP Pavilion ZT3000 - regression from breezy

Well, suspend works for me, but hibernate works/screws-up in a very peculiar pattern. After a boot (or resume from hibernation), the first time I try to hibernate, it doesnt work. The screen goes blank and returns to its normal self within a few seconds. The The second time I hit the hibernate button in the logoff menu, it works. However, like said before, if hibernated on battery, it "hangs midway with the disk light permanently on. The only thing I can do from there is hold down the power button and hard-power-off the machine."
Arjun Shankar

Forgot to mention that im running Dapper Flight 5.

Can you try and wait 10 minutes? It powers off after an insanely long amount with my laptop, but it works always.
I have the exact same indications.

I have the same problem with a Dell D410. All said above holds
for this laptop too.

I also have the same problem on a Sony Vaio VGN-S260. Suspend to RAM works under both Breezy and Dapper, and hibernate works properly under Breezy. But I have the same problem as mentioned above with hibernation failing under Dapper.

I want a little bit of clarification: Do you both get the same issue I described or the issue the original reporter described, i. e. does it work and just takes a long time or doesn't it work at all.

If you want to try that, prepare to leave your laptop sitting there for 30 minutes or so.

And as a side note, this is still present in 2.6.15-20 in dapper.

at first I thought I was having this problem
https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/36736/+index
but this seems more like the issue I am having. Although it does this with suspend (ibm T41, Fn+F4) for me (going to try with hibernate, just want to post first since it will probably just lockup again). Would me being a rebel and deciding I do not need a swap partition be part of the problem? (guessing hibernate will not work since i do not have swap) I have 512MB RAM which I figured should be enough... I also tried leaving it sit for about 10 minutes but it would not come back.

Disabling laptop-mode fixed it for me, so it must be a bug in that, kinda sucks though.
I did this
sudo nano /etc/laptop-mode/laptop-mode.conf
and changed it so it is not enabled when on battery. I rebooted (by just using the init scrips to restart it did not work) and suddenly suspend and hibernate work. Although suddenly I cannot open that file so I can show you what I changed. now i get:
nano: error while loading shared libraries: /lib/libncursesw.so.5: cannot read file data: Input/output error

and it opened fine just before i put it to sleep (also put it into hibernation, both worked, and it has worked 5 times in a row so far, so i ma fairly confident that the problem is laptop-mode)

As you can see from the heading, I'm having more general problem with hibernation.

I'm using an MSI S 250 and I have these lock-ups as well with AC-power and when running on battery. I have Dapper Flight 6.
uname -rv: 2.6.15-20-686 #1 SMP PREEMPT Tue Apr 4 18:37:00 UTC 2006

I thought first that the machine just stops responding and after a few minutes shut it down with the power button. Then I read your posts and knew to wait a little longer and indeed the machine does hibernate after an insanely long time. It takes something like ten minutes to do so.

This doesn't happen every time, but approximately every second or third time, I would say.

Moreover, I would like to know what happened to that password-protection we had in Breezy? My machine doesn't ask for a password when it wakes from hibernation. I would like it to do so, for security reasons - now anybody can continue my session and access all my data without any hacking.

The following info is gathered by continuously suspending (by closing the lid) and resuming. I let 5 minutes pass between each event so I can track them easily from the logs.

Debug info follows:

-----

lspci:

0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] 661FX/M661FX/M661MX Host (rev 11)
0000:00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-to-PCI bridge)
0000:00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (rev 25)
0000:00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
0000:00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
0000:00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0)
0000:00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound Controller (rev a0)
0000:00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
0000:00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
0000:00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
0000:00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90)
0000:00:09.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
0000:00:09.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
0000:00:09.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 04)
0000:00:0e.0 Network controller: RaLink Ralink RT2500 802.11 Cardbus Reference Card (rev 01)
0000:01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760/761 PCI/AGP VGA Display Adapter

-----
syslog:

** At 08:55 did a suspend with AC-Power and the machine hanged **

Apr 15 08:55:22 localhost gnome-power-manager: Hibernating computer because the lid has been closed on ac power
Apr 15 08:55:22 localhost kernel: [4333192.015000] pccard: card ejected from slot 0
Apr 15 08:55:22 localhost dhclient: Internet Systems Consortium DHCP Client V3.0.3
Apr 15 08:55:22 localhost dhclient: Copyright 2004-2005 Internet Systems Consortium.
Apr 15 08:55:22 localhost dhclient: All rights reserved.
Apr 15 08:55:22 localhost dhclient: For info, please visit http://www.isc.org/products/DH...

I can confirm that it's due to laptop-mode, without it, it suspended as expected

I get it on my thinkpad T30, too.

ASUSTeK Computer Inc.
M6Ne
1.0

even in my case hibernation on battery takes more than 10 minutes
but I'm not affected by the problem in the second post

I should point out that hibernate fails for me on my Thinkpad T30 reliably under these conditions:

1) Power is connectioned
2) Click on gnome power manager notification area icon, select hibernate
3) unplug laptop during hibernation process
4) laptop will hang with harddrive activity and sleep status lights lit until the battery runs out.

I seem to be able to hibernate reliably if I'm plugged in and remain plugged in during the process.
I seem to be able to hibernate reliably if I'm not plugged in when I tell it to hibernate.

I haven't yet tried hibernating while unplugged and plugging into AC during the hibernation process.

Actually, hibernation without AC at all is not 100% reliable. It often works, but occaisionally fails.

I have the same problem with a Dell Latitude D810. With AC power, hibernation works. Without AC power, the system freezes. Turning off laptop mode and waiting for 5 minutes doesn't help.

This is also reported as Bug #40034 on acpi-support.

I can confirm this on this machine: https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadR50e

Hibernating without AC plugged in takes more than 10 minutes!

The most recent acpi-support updates seem to have fixed this, at least most of the way. Hibernation is now much quicker (happens in some number of seconds, rather than 10s of minutes) on my Sony laptop.

Yeah, here's the changelog snippet:

acpi-support (0.72) dapper; urgency=low

  * Re-disable laptop-mode by default, to work around LP#12483
    - Has the pleasant side effect of making the comment match the code

 -- Matt Zimmerman <email address hidden> Sat, 22 Apr 2006 05:34:12 -0700

Which raises the question, is this bug a dupe of bug 12483?

>> grep -i laptop_mode /etc/default/acpi-support
ENABLE_LAPTOP_MODE=false

and I'm affected as well :(

This bug still affects my machine (MSI S250), even though the laptop mode is disabled.

Yesterday saw a major update and after I restarted the machine this has now happened two times. That is every time I have initiated the hibernation since then =(

The slow hibernate on battery is also problem on both the MSI 1013 and 1029 laptops using the latest dapper updates (S270 and M635 retail models)
Disabling laptop mode in both /etc/default/acpi-support and /etc/laptop-mode/laptop-mode.conf had no effect.
Is the problem really laptop-mode or could something else cause this symptom? I might try disabling laptop-mode in the kernel.

I informed Bart Samwel of this bug. He is heavily involved with the development of laptop-mode. Let's see if he has any insight about this matter.

Hi everybody,

I've looked through the reports, and there were two things that drew my attention:

 * Hibernation happens as a result of ACPI lid events. laptop-mode-tools also registers an ACPI lid event and calls "/usr/sbin/laptop_mode auto" as a result. This may cause the hibernation and the laptop mode script to run in parallel.

* Michael R. Head noticed that hibernation would take forever when the laptop was unplugged during hibernation. Again, unplugging the laptop triggers an ACPI event registered by laptop-mode-tools, which triggers "/usr/sbin/laptop_mode auto". Again, this may cause the hibernation and the laptop mode script to run in parallel.

Apparently the running of "/usr/sbin/laptop_mode auto" during or close to hibernation is troublesome. I can imagine that this may be the case because it (a) calls lots of programs, and (b) twiddles with the hardware and with kernel settings. Perhpas some of the programs called by laptop mode don't like to be put in the freezer.

Potential solution 1: disable the laptop-mode service during hibernation.
Won't work because: laptop-mode-tools also listens on the lid event, and may therefore run _in parallel_ with the hibernation script.

Potential solution 2: integrate the lid events of laptop-mode-tools and hibernate, so that laptop-mode-tools and hibernate are run serially. Then disable the laptop-mode service during hibernation as well.

Solution (2) would probably work.

Thank you Bart for such a quick reply =)

I can confirm that hibernation through the menu works great, while the lid-close seems to hang. This also works when the menu is brought up by pressing the power button.

Interestingly when the hibernation is initiated by the menu item, it doesn't trigger the screen locking of the gnome-screensaver.

Mikko Saarinen wrote:
> Thank you Bart for such a quick reply =)
>
> I can confirm that hibernation through the menu works great, while the lid-close seems to hang. This also works when the menu is brought up by pressing the power button.

OK. This means solution (2). Who is responsible for the lid response
script, is that Matt Zimmerman? I've CC'ed him, perhaps he'll want to
take a look at this as well.

> Interestingly when the hibernation is initiated by the menu item, it doesn't trigger the screen locking of the gnome-screensaver.

Hmmm. Perhaps the screen locking is implemented by the lid button
response script and not by the hibernation per se?

Cheers,
Bart

/etc/acpi/lid.sh is from acpi-support for which Matthew Garrett seems responsible, so I will suscribe him.

I'm not entirely sure on this. I had this slow-hibernate problem on Dapper for a while, then it worked for a short while (acpi-support v0.72 I think, though I may be wrong), and last night when I went to hibernate my laptop by right-clicking on the Gnome Power Manager applet, the hibernation took more than 10 minutes. I did not try to close the lid during the hibernation, I just selected "hibernate" from the applet's right-click menu.

laptop-mode-tools doesn't receive any acpi events under ubuntu. I'm still looking into this problem.

Matthew Garrett wrote:
> laptop-mode-tools doesn't receive any acpi events under ubuntu. I'm
> still looking into this problem.

Hmmm, that rules out interference of the laptop_mode script. It must be
one of the kernel settings then.

To check if it's the laptop_mode setting itself, can somebody try doing
"cat 0 > /proc/sys/vm/laptop_mode" while laptop mode _is_ enabled, and
then hibernate, and see if the problem still occurs?

The slow hibernate on battery is also problem on both the MSI 1013 and 1029 laptops using the latest dapper updates (S270 and M635 retail models)
Disabling laptop mode in both /etc/default/acpi-support and /etc/laptop-mode/laptop-mode.conf had no effect.
Is the problem really laptop-mode or could something else cause this symptom? I might try disabling laptop-mode in the kernel.

...sorry, my last post was a dup due to a page refresh..

>> can somebody try doing "cat 0 > /proc/sys/vm/laptop_mode" while laptop mode _is_ enabled

How is that different than "laptop_mode stop"? In any case, "laptop_mode start; echo 0 > /proc/sys/vm/laptop_mode" doesn't change anything, same problem. I usually check laptop_mode status before hibernation, and having it disabled, removing /var/run/laptop-mode-enabled, etc. doesn't help.

This appears to prevent the slow hibernation while on battery problem:
apt-get remove laptop-mode-tools
(which will also remove due to dependencies: acpi-support gnome-power-manager laptop-mode-tools powermanagement-interface ubuntu-desktop)

Of course, without some of those other packages there are other problems (like the network not coming back up correctly)

DEBUGGING TIP: if you change your kernel parameters to remove quiet and splash and add vga=normal, and in /etc/default/acpi-support you set USE_DPMS=false then you should be able to see your notebook's status while hibernating including a % of pages written to memory so you know if hibernation is hung or just really slow (can take up to 30 minutes sometimes)

Here is a new easier workaround without removing all those packages (or using dpkg --force-all -r laptop-mode-tools, which will cause dependency problems later):

sudo mv /usr/sbin/laptop_mode /usr/sbin/laptop_mode.disabled

(of course upgrading to a new laptop-mode-tools package will put that file back into place, but hopefully it contains a fix for this by then)

Looking at that script, even when laptop mode is turned off in the config files it still writes some information to /proc/sys/... to shut laptop mode off, and I suspect that somehow that is screwing up the kernel/hard drive during hibernation writing.

So, we have two problems here:
problem #1-- laptop mode screws things up even when it is completely "disabled" in config files or "stopped" . A quick fix for this would be to check if laptop-mode was never enabled and if not, do nothing for the "stop" action instead of "Adjusting 2.6 kernel parameters to disable laptop mode." (line 1038)
problem #2-- enabling laptop mode causes extremely slow hard drive writing during battery powered hibernation. This sounds like it could be a lot harder to fix.

I won't be delving into this any further for a while, but I'd be happy to do more testing if there is a fix.

Note that the kernel parameters set by "laptop_mode stop" are exactly the kernel defaults, so that shouldn't make any difference. Also, I'm sure that no action is taken in the kernel as a result of changing those settings to the same values that they were already at.

Anyway, it may be the hdparm settings, the readahead settings or the remounts that screw things up. Could you try changing the following values in laptop-mode.conf to "0", one by one, trying if it still fails after each one:

CONTROL_READAHEAD
CONTROL_HD_POWERMGMT
CONTROL_HD_WRITECACHE
CONTROL_HD_IDLE_TIMEOUT
CONTROL_MOUNT_OPTIONS

That should yield a very clear picture of what the cause is!

right after I left that last message I started thinking about hdparm...
long story short, it is the write cache control, which makes perfect sense -- if you turn off the hard drive write caching, writes could be painfully slow.
So, the solution is to set
CONTROL_HD_WRITECACHE=0
in /etc/laptop-mode/laptop-mode.conf
and everything seems to work great. If I set it back to 1, it is slow again, so I'm pretty confident this is it.
Thanks!

I did this too and I also re-enabled the laptop-mode in /etc/default/acpi-support and now my machine is working normally (suspended it twice after a reboot, both finished in less than a minute). I did also some pre-emptive testing by setting the action of lid-close to suspend, rather than hibernate and it is also working great.

Thanks for you both Michael and Bart. This was the largest issue I've had with my laptop since I installed Dapper and now it seems to be fixed =)

The only question is how much more power is consumed without the writecache option? I have very poor battery life already...

I'm glad it's solved!

BTW, the default value for CONTROL_HD_WRITECACHE was already changed to 0 in version 1.20 of the upstream laptop-mode-tools package. Turning the HD writecache off while in laptop mode originally seemed like the "safe choice" -- to prevent the hard drive from spinning down while it hasn't written back all data yet. However, it turned out that in reality, hard drives never spin down while retaining unwritten data in the cache. So the option is best left turned off. In fact, I think I'll remove it. :-)

I can confirm that also my Dell D410 laptop can now
successfully hibernate under dapper with the
above modification (with and without laptop mode
enabled). Thanks.

(But why was it working under Breezy on the
same machine?)

Martin Escardo wrote:
> (But why was it working under Breezy on the
> same machine?)

Because the included version 1.05 of laptop-mode-tools didn't do
writecache control. This was added in 1.06 and disabled by default in 1.20.

Bart Samwell writes:
> > (But why was it working under Breezy on the
> > same machine?)

> Because the included version 1.05 of laptop-mode-tools didn't do
> writecache control. This was added in 1.06 and disabled by default in 1.20.

Ah, I see.

BTW: The installer I used (Flight 7) makes the swap smaller (~700Mb)
than the RAM (1Gb in my case) by default. I paid attention to this
this time, and took action, but under Breezy I failed to get
hibernation working the first time because of this unreasonable
default. Then I had to go through the trouble making a swap partition
myself (after I discovered that this was wrong), setting grub
parameters etc. I hope, for the sake of new Ubuntu laptop users, that
this will be fixed in the installer for the release version!

I can report that disabling the writecache has allows my thinkpad T30 to hibernate while on battery. I'll keep testing this and report back if I get any hibernation failures in the future.

On Thu, 2006-04-27 at 15:47 +0000, Martin Escardo wrote:
> Bart Samwell writes:
>
> Ah, I see.
>
> BTW: The installer I used (Flight 7) makes the swap smaller (~700Mb)
> than the RAM (1Gb in my case) by default. I paid attention to this

How big is your harddrive?

--
Michael R. Head <email address hidden>
GPG: http://www.suppressingfire.org/~burner/gpg.key.txt [0x4C9DA1D0]

Michael R. Head writes:
> > BTW: The installer I used (Flight 7) makes the swap smaller (~700Mb)
> > than the RAM (1Gb in my case) by default.
>
> How big is your harddrive?

Does that matter much? We are talking about a swap partition that is
only 300Mb smaller than it should be for hibernation to work.

The partition for dapper is >14GB at the moment. The hd is much bigger
than that. But also for breezy, whose partition is >20Gb, the
installation CD allocated less than the RAM.

Should be fixed with the latest laptop-mode-tools upload