Hibernate fails on Thinkpad T41

[Ulrich Hobelmann]

I've installed Ubuntu 8.10 (Intrepid) on my Thinkpad T41 (which previously had 8.04 installed) and got all updates available.

I can hibernate, and the hard-disk light indicates that memory state is saved to the disk. When I start the machine again, the kernel boots, the Ubuntu splash screen appears (all as in 8.04), and the disk light indicates that memory is initialized again. However, after that, the machine locks up, nothing more happens, except the Caps-lock LED flashing Ctrl-alt-F1-9 did not do anything, i.e. there was no way I could find out what's wrong. I also did not find anything relevant in /var/log/dmesg* or /var/log/syslog* (at least from my view; I'm no kernel hacker).

When hibernating, the T41 switches the screen to text/console mode with just a blinking _ cursor. On 8.10, I now get a message about "PCI" and "unable to thaw device" or something like it, which may be relevant to this behavior. (yes, the "thaw..." message appears not on resuming, but on hibernating)

kernel is 2.6.27-7-generic #1 SMP Fri Oct 10 03:55:24 UTC 2008 i686 (from uname -a)

I'm unsure if this bug is related to bug #134680.

[Ulrich Hobelmann (u-hobelmann)]

Resume from "suspend" also fails, so maybe it's not the going to sleep after all, but the wakeup doesn't do what it's supposed to.

[Paul Broadhead (pjbroad)]

I have exactly the same behaviour on my Thinkpad X31, fully updated 8.10. For hardy, hibernate had always worked faultlessly. The machine does occasionally resume successfully. On initial hibernate, I get a thaw error of -16, the full messages disappears before I can write it down but I'll capture it if it is important.

I have also edited the grub boot line on start-up to remove the "quiet" and "splash" words.
This is the console output I see (I may have made type errors):
...
PM: Starting manual resume from disk
Freezing user space processes ... (elapse 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapse 0.00 seconds) done.
PM: Loading image data pages (110237 pages) ... done
PM: Read 476948 kbytes in 27.20 seconds (17.53 MB/s)
Suspend console(s) (use no_console_suspend to debug)

The machine then freezes, flashing the caps lock light at about 1Hz.

I tried resuming from suspend with the no_console_suspend flag attached to the boot line (is that what I was meant to try?) and each time the machine resumed successfully.

[Paul Broadhead (pjbroad)]

> I tried resuming from suspend with the no_console_suspend flag...
Sorry that should have been resuming from "hibernate"

[Ulrich Hobelmann (u-hobelmann)]

I think there was a kernel upgrade a few days ago, so I decided to retry this.

This morning I hibernated the T41, and now it restarted correctly (even though it still printed that "unable to thaw" message on hibernate). If this is reproducible by others, and if I resuming keeps working on my system the next couple of days, this bug may have been fixed.

[Ulrich Hobelmann (u-hobelmann)]

Sometimes it works, but right now the computer froze again on resume...

So it's probably not deterministic.

[Ulrich Hobelmann (u-hobelmann)]

Most of the time it seems to work reliably, better anyway than the Mac I used to own a few years ago.

[Paul Broadhead (pjbroad)]

Re: X31 laptop. At some stage during the run-up to release, my hibernate problem was much improved. I started hibernating all the time again. The latest updates have caused the problem to return to its worst. I can no longer use hibernate. Sorry to be so vague about versions but they were obviosuly coming in think and fast as release approached.

[Ulrich Hobelmann (u-hobelmann)]

Last night there was another kernel update or something.

Now the Thinkpad fails to resume again (twice so far; I won't try again).

2.6.27-7-generic #1 SMP Tue Nov 4 19:33:20 UTC 2008 i686 GNU/Linux

[Radomír Černoch (radomir-cernoch)]

When resuming the system from "suspend to disk", the machine freezes completely. I am using a fresh openSUSE 11.1-RC1 with 2.6.27.7-4-default kernel on IBM ThinkPad T42.

It is very likely that the problem is related to the graphical card as it hangs approximately around the time, when X server gets started. Moreover after the freeze CapsLock LED starts blinking, which resemlbes me the struggle with proprietal ATI drivers on a different notebook.

The problem does not occur during suspend/resume to/from RAM.

[Radomír Černoch (radomir-cernoch)]

Created an attachment (id=256746)
/var/log/pm-suspend.log

[Radomír Černoch (radomir-cernoch)]

Created an attachment (id=256747)
Output of 'lshal'

[Stefan Seyfried (seife)]

The log file shows that the machine suspends and resumes wonderfully, so if it hangs when switching back to X it is most likely a X server issue.

[Mhopf (mhopf)]

Can you verify by switching to console before suspending whether the machine crashes upon resume as well? Or only after you switch back manually after that?

[Radomír Černoch (radomir-cernoch)]

I have done some more testing today and after a few dozens of suspend/resume I am quite sure that:
1) The problem is independent of being on the console or in X.
2) It is also independent of whether the X server running when suspending from console.
3) It is independent of using the standard framebuffer or the 'radeonfb' module.
4) I haven't tested switching the X from 'radeon' driver to 'vesa'. Should I?

But!!! I have realized that the system freezes during resume if and only if the power was removed and reattached during the hibernation. There is a 100% accurancy on this.

I think that the problem is caused by erasing the graphical chip's memory when the power adaptor is removed. It would explain the fact, that the system works well until it switches from the "suspend console" (the one which shows the progress of suspend/resume; sorry for not knowing the right name) to either the normal console (tty0..5) or X server. Moreover it would also fit the perfectly reliable suspending to RAM (the graphic card memory's power supply should be still on during s2ram).

However I am not sure, in which part of the system the bug has appeared. I just know that the suspend to disk worked well on openSUSE 10.3...

[Rjw-novell (rjw-novell)]

This almost certainly is a kernel issue.

Your observation that the failure only happens if AC power is removed during hibernation seems to indicate and ACPI problem.

What happens if you hibernate and resume on battery?

[Radomír Černoch (radomir-cernoch)]

Suspend/resume (s&r) from battery causes a freeze always. The only difference is that the blinking CapsLock blinks slower as the CPU frequency is lower ;-). I have even tried pluging in the AC during the hibernation, but without a success.

Actually the ACPI was the first thing that came to my mind. But why would the system freeze always at the point when the "suspend console" (Does it have a proper name?) switches back to either X server or normal console (tty)? The memory corruption of GPU seems more logical, doesn't it? And do you know any way, how this could be debugged?

In case it was a kernel (or X?) bug, who should I contact first? And is there a way how to some kind of kernel oops in such conditions?

Sorry for lots of questions. :-)

[Rjw-novell (rjw-novell)]

(In reply to comment #7 from Radomír Černoch)
> Suspend/resume (s&r) from battery causes a freeze always. The only difference
> is that the blinking CapsLock blinks slower as the CPU frequency is
> lower ;-).
> I have even tried pluging in the AC during the hibernation, but without a
> success.

So, the box always crashes during resume from hibernation if it has been hibernated on battery power. Is that correct?

If that is the case, have you tried to unload the battery module before hibernation?

> Actually the ACPI was the first thing that came to my mind. But why would the
> system freeze always at the point when the "suspend console" (Does it have a
> proper name?) switches back to either X server or normal console (tty)?

Devices are being resumed at that point.

> The memory corruption of GPU seems more logical, doesn't it?

Not necessarily. Your observations made in comment #5 pretty much exclude an X issue, unless they are incorrect. ;-)

> And do you know any way, how this could be debugged?
>
> In case it was a kernel (or X?) bug, who should I contact first? And is
> there a way how to some kind of kernel oops in such conditions?

First, as I said before, I think it is a kernel issue. Second, as you said the box worked correctly with the kernel from openSUSE 10.3, do you have any experience with building and installing the kernel yourself?

[Radomír Černoch (radomir-cernoch)]

> So, the box always crashes during resume from hibernation if it has been
> hibernated on battery power. Is that correct?

Not exactly. Putting all evidence together the notebook crashes always when it goes on battery (at least for a while) during the hibernation (when it is already turned off). Running the actual process of suspending or hibernation from battery or AC makes no difference.

> If that is the case, have you tried to unload the battery module before
> hibernation?

Wow, this helps! Unloading the battery makes the hibernation safe. (tested 3x)

> Devices are being resumed at that point.
> ...
> Not necessarily. Your observations made in comment #5 pretty much
> exclude an X issue, unless they are incorrect. ;-)

Oh, I didn't know. It seems that I'm faster writing than thinking :-) Sorry.

> First, as I said before, I think it is a kernel issue. Second, as you
> said the box worked correctly with the kernel from openSUSE 10.3, do
> you have any experience with building and installing the kernel yourself?

There should not be any problem about it.

[Trenn-novell (trenn-novell)]

> And do you know any way, how this could be debugged?
> And is there away how to some kind of kernel oops in such conditions?
Serial console?
> IBM ThinkPad T42
This should still have one?
There is a boot option (I do not find it in kernel-parameters?), to keep the console up during suspend/resume.
You might want to increase the ACPI output first:
echo 0x1f >/sys/module/acpi/parameters/debug_level
or even (can be a lot output):
echo 0x21f >/sys/module/acpi/parameters/debug_level

Then suspend and check the last lines it executes you see on serial console (with this boot param to not disable serial) when it freezes. If it points to ACPI, attach acpidump output of the system. Rafael/Pavel might want to correct/enhance my comments.

BTW: Is this possibly related to a Docking station?

[Radomír Černoch (radomir-cernoch)]

(In reply to comment #10 from Thomas Renninger)
> Serial console?
> This should still have one?

Unfortunately not. A serial port can be accessed through the docking station, which I do not have. Do you think it would be possible to do this through USB-serial converter if the appropriate module was inserted into initrd?

> If it points to ACPI, attach acpidump output of the system.

Doesn't the fact, that removal of 'battery' module makes the system work reliably, actually show that it is an ACPI problem? I would like to give you the info from the serial console, but currently I am lacking the equipment...

> BTW: Is this possibly related to a Docking station?

The notebook is not attached to a docking station. Nevertheless I cannot rule out the possibility that some part of openSUSE responsible of docking is actually causing the trouble.

[Ulrich Hobelmann (u-hobelmann)]

Works like a charm again: 2.6.27-9-generic #1 SMP (seems like I missed an update; not sure how -8 would have worked out).

[Trenn-novell (trenn-novell)]

> Do you think it would be possible to do this through USB-serial converter
No, it could be done via firewire (firescope), but I doubt you have that HW.

I expect all we can do is what Rafael already suggested:
  - If that is the case, have you tried to unload the battery module before
    hibernation?
  - Second, as you said the box worked correctly with the kernel from openSUSE
    10.3, do you have any experience with building and installing the kernel
    yourself
For the latter, he probably thinks about git bisecting.
You have to get the latest git kernel and use git bisect (passing the last kernel which you know worked).
You then have build, install and boot the newly built kernel.
Then tell git bisect whether it worked or not and it will choose the next set of patches worth testing until the offending patch is found.
On a first round you might want try out with the latest vanilla kernels (.28-rcX -> maybe it's already fixed?, .27 -> maybe it's a SUSE patch?, .26 -> if it works it's a nice starting point for git bisect).
For getting the latest Linux kernel git sources do:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 linux-2.6

Finding the offending patch can be cumbersome, maybe someone has a better idea, I do not have any.

[Radomír Černoch (radomir-cernoch)]

(In reply to comment #12 from Thomas Renninger)
> No, it could be done via firewire (firescope), but I doubt you have that HW.

Right, I do not have this device. :-(

> I expect all we can do is what Rafael already suggested:
> - If that is the case, have you tried to unload the battery module before
> hibernation?

As I have already written, unloading the "battery" module helps and the suspend/resume becomes reliable.

> For the latter, he probably thinks about git bisecting.

Ok, I will try the bisecting.

I already have some experience with building a custom vanilla kernel. But from the last time I tried it (~ 2.6.14), something must have changed in the system: When doing the sequence
# make oldconfig
# make
# make install
# make modules_install
# mkinitrd
the newly installed kernel can no longer find the root partition. Is there a turotial for building vanilla kernels on openSUSE?

[Mhopf (mhopf)]

As this is not X related, I reassign this to you Thomas, ok?

[Radomír Černoch (radomir-cernoch)]

(In reply to comment #13 from Radomír Černoch)
> I already have some experience with building a custom vanilla kernel. But from
> the last time I tried it (~ 2.6.14), something must have changed in the system:
> When doing the sequence
> # make oldconfig
> # make
> # make install
> # make modules_install
> # mkinitrd
> the newly installed kernel can no longer find the root partition. Is there a
> turotial for building vanilla kernels on openSUSE?

I do no longer need the help (just a few modules got renamed from vanilla to SUSE flavour). I am starting the bisection... 4000 revisions to go...

I will let you know ASAP.

[Radomír Černoch (radomir-cernoch)]

Created an attachment (id=258046)
Result of bisection

After the bisection, git produced the output, which is attached as 'git_message.txt'. Should I post it to LKML as well?

PS: I found bisection as quite an interesting process, just like playing golf. More strokes you make, the smaller leaps to the pin you make. But the price of all of them is the same.

[Trenn-novell (trenn-novell)]

Wow! Well done and thanks!
Rafael, this looks like a bug for you...

> Should I post it to LKML as well
That's Rafael to decide, he probably will be the one who will look at this in the end anyway?
Also posting on linux-acpi list should be enough to make this more public.

[Radomír Černoch (radomir-cernoch)]

(In reply to comment #17 from Thomas Renninger)
> That's Rafael to decide, he probably will be the one who will look at this in
> the end anyway?

Ok, so far I am not posting anything anywhere. If you needed some more info or testing, just drop me an e-mail.

[Radomír Černoch (radomir-cernoch)]

Sorry, it is very likely that I gave you misleading information. The most recent version of the kernel, which does not have the bug, has crashed today.

Currently I do not know anything more about the possible flaw -- this revision was already tested. I will let you know when more (and repeatitive) tests will be done.

[Radomír Černoch (radomir-cernoch)]

Created an attachment (id=258385)
Result of bisection v2

The final result of bisecting the kernel is in the attachment.

Sorry once more for sending you wrong info. This time both kernels (last good and first bad) have been tested 4 times, double checking that the version of tested kernel is the same as in git. The good kernel has never crashed during resume and the bad one has crashed always. I hope that there can't be a flaw any more.

[Rjw-novell (rjw-novell)]

Please add the 'acpi_sleep=s4_nohwsig' option to the kernel command line.

Apparently, your BIOS doesn't handle the ACPI hardware signature correctly.

[Radomír Černoch (radomir-cernoch)]

I can confirm that passing 'acpi_sleep=s4_nohwsig' helps and the machine resumes correctly. What should I do next?

[Rjw-novell (rjw-novell)]

Please provide the output of 'dmidecode' from your system, so that I can prepare a blacklisting patch for it.

[Radomír Černoch (radomir-cernoch)]

Created an attachment (id=258754)
Output of 'dmidecode'

By the way, do you have an idea, how many systems could be affected, by this? I was just wondering, whether it is worth adding any kind of GUI checkbox somewhere in YaST to activate the workaroung you sent me.

[Rjw-novell (rjw-novell)]

(In reply to comment #24 from Radomír Černoch)
> Created an attachment (id=258754) [details]
> Output of 'dmidecode'

Thanks, I'm going to take care of this tomorrow.

> By the way, do you have an idea, how many systems could be affected, by this?
> I was just wondering, whether it is worth adding any kind of GUI checkbox
> somewhere in YaST to activate the workaroung you sent me.

Well, you're the first person reporting it and so far the only one, so I guess not too many. ;-)

[Rjw-novell (rjw-novell)]

Created an attachment (id=259283)
Prevent Thinkpad T42 from using the ACPI S4 hardware signature

With this patch applied your box should successfully resume from hibernation without the acpi_sleep=s4_nohwsig command line parameter.

[Radomír Černoch (radomir-cernoch)]

Sorry for the delay. I can confirm that this patch works well for my machine; 'acpi_sleep=s4_nohwsig' is no longer needed.

Thanks for help.

[Rjw-novell (rjw-novell)]

Thanks for testing.

I'm still waiting for the confirmation that other T42s are also affected. If this problem occurs on your system only, I'd prefer not to apply the patch.

[Rjw-novell (rjw-novell)]

I'll close the bug when it is known if all T42s are affected.

[Lmuelle (lmuelle)]

A X31 ThinkPad shows sometimes the the same behavior while resume resume after suspend to disk. Before the upgrade from 10.3 to 11.1 resume after suspend to disk worked well.

I've added "acpi_sleep=s4_nohwsig" to the kernel command line and suspended and resumed five times without seeing the issue again.

Output of dmidecode of the X31 system follows.

[Lmuelle (lmuelle)]

Created an attachment (id=263119)
stdout of dmidecode on a ThinkPad x31

[Lmuelle (lmuelle)]

Created an attachment (id=263122)
Stdtout of dmidecode on a ThinkPad x31

Output of dmidecode after the update of the embedded controller (1.08) and the BIOS (3.02) of the X31.

[Stefan Seyfried (seife)]

Lars, it might be interesting to test if you sill need s4_nohwsig after the BIOS update (yes, IBM/Lenovo sometimes fix stuff in their BIOS updates ;)

[Lmuelle (lmuelle)]

After an update of the embedded controller (1.08) and the BIOS (3.02) s4_nohwsig is no longer required by the X31 for a working suspend and resume. I've tested it more than ten times.

@Radomír: Your embedded controller is up to date. But your BIOS isn't. Lenovo offers version 3.23 while you're at 3.13.

After my experience with the X31 I like to see you updating the BIOS. See http://www.thinkwiki.org/wiki/BIOS_Upgrade/X_Series approach #7 if you don't like to create bootable floppy disks.

[Radomír Černoch (radomir-cernoch)]

Yes, I can confirm that after the BIOS update, 's4_nohwsig' is not needed to make suspend/resume work.

[Rjw-novell (rjw-novell)]

So in fact this turns out to be a BIOS bug.

I think we can close this entry now, any objections?

[Radomír Černoch (radomir-cernoch)]

I am just thinking, whether we should force users of all affected systems to update their BIOS. It is not a user-friendly process without Windows. Is the "ACPI hardware signature" so important?

[Rjw-novell (rjw-novell)]

It's a hardware feature we're supposed to use and it works with the vast majority of hardware from what I can tell.

The general policy is to blacklist systems that have problems with it, but since on Thinkpads the BIOS update evidently helps, I don't think we should blacklist them.

The users of affected system who don't want to upgrade their BIOSes can still use the acpi_sleep=s4_nohwsig kernel option as a workaround to make hibernation work (that's what the option is for after all).

[Radomír Černoch (radomir-cernoch)]

OK, what you wrote is reasonable. Anyway there should be a notice about this problem somewhere. Shall I put a short notice in http://en.opensuse.org/S2disk ?

[Rjw-novell (rjw-novell)]

Please do.

[Rodrigo Daunoravicius (rodelrod)]

I'm running Ubuntu 8.10 Intrepid, not OpenSuse, but as this seems to be a kernel problem and as I can't find the issue discussed anywhere else I'll report here.

With the kernel 2.6.27-11-generic on a Thinkpad X32, even after updating the BIOS (3.02) and embedded controller (1.08), I experience the same problems resuming if the AC power is unplugged during hibernation.

With the 'acpi_sleep=s4_nohwsig' kernel option, it resumes correctly.

[Ranxerox (software-doorways)]

T42 8.10
Linux Mobility 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux

3/4 of the time won't start up after hibernate

Found this online:

"When i upgraded ubuntu to 8.10 i noticed that my ubuntu don't resume from hibernation when i unplug power cord after my laptop is hibernated and then plug in it back my laptop freezes with kernel panic ( blinking caps lock ). When i hibernate and resume with power cord plugged it resume without problem."

(http://ubuntuforums.org/showthread.php?t=990183)

Haven't verified this is the same pattern but it feels right. I generally follow that pattern (work at home plugged in, hibernate, restart on bus w/o plug, etc.) except on weekends when it seems to work all fine.

I'm going to try unplugging before hibernating for a while and if it 'fixes' the issue I'll post back here.

[Ranxerox (software-doorways)]

Doesn't seem to make any difference. The pattern from the previous comment doesn't look like it describes the behavior.

Is there some way to switch off the splash screen during startup so that I can watch what is happening and figure out what step is hanging the system? I'd like to gather more data on this problem.

[Ranxerox (software-doorways)]

I altered /boot/grub/menu.lst to turn off the splash screen. When I restart after a hibernate it gives a message that it's booting from a stored image (not exact message but the sense of it) and then nothing until the caps lock icon starts blinking. Oh, well, it was worth a shot.

[Ranxerox (software-doorways)]

I removed the quiet flag from /boot/grub/menu.lst. I got the following at the end:

kinit: trying to resume from /dev/disk/by-uuid/[GUID]
[ 4.066500] PM: Starting manual resume from disk
[ 4.067022] Freezing user space processes ... (elapsed 0.00 seconds) done.
[ 4.067128] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
[ 4.067642] PM: Loading image data pages (110598 pages) ... done
[26.414556] PM: 442392 kbytes in 22.34 seconds (19.80 MB/s)
[26.414621] Suspending console(s) (use no_console_suspend to debug)

I left it sitting with the caps lock blinking for 10 minutes or more.

[Ranxerox (software-doorways)]

I added the no_console_suspend flag to /boot/grub/menu.lst. This produced some more data but didn't fix the problem. Here's the new data, with the changing numbers replaced with bracketed place holders:

[TIME] PM: Loading image data pages ([PAGES] pages) ... done
[TIME] PM: Read [KBYTES] kbytes in [SECS] seconds ([MBYTES] MB/s)
[TIME] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[TIME] serial 00:09: disabled
[TIME] ata-piix 0000:00:1f.1: PCI INT A disabled
[TIME] ehci_hcd 0000:00:1d.7: PCI INT D disabled
[TIME] uhci_hcd 0000:00:1d.2: PCI INT C disabled
[TIME] uhci_hcd 0000:00:1d.1: PCI INT B disabled
[TIME] uhci_hcd 0000:00:1d.0: PCI INT A disabled
[TIME] Disabling non-boot CPUs ...
[TIME] Extended CMLS year 2000

I ran the test twice and it hung at this point both times.

I should note that the test goes like this:

* boot machine with power cord plugged in
* hibernate with power cord still plugged in
* remove power cord
* thaw (push power button to restart from hibernate) on batter power
* hang

Despite my earlier comment, this shift from AC to batter while hibernated does seem to make the hang reproducible thus far. So perhaps that pattern is important after all.

[XiFu (xifu)]

I have exactly the same problem with my ThinkPad X31!

The problem seems to be a result of wrong BIOS messages from the ThinkPad.

In a Novell bugreport, they advise to either update the BIOS or add a kernel parameter at startup.

I tried the solution with the parameter, and it seems to work for me.

I added the parameter "acpi_sleep=s4_nohwsig" to the "# defoptions=quiet splash" section in /boot/grub/menu.lst and did a "sudo update-grub".
Please see, if it works for you too.

Source: https://bugzilla.novell.com/show_bug.cgi?id=450256

[Ranxerox (software-doorways)]

I tried that but it didn't work for me. I may not know how to install a kernel option. I had previously been adding parameters to the first menu option. It seemed odd that you would add something to the defoptions line and not uncomment it so I tried it both ways. I added the parameters to the first menu item as I had been doing. Nothing made any difference, with or without sudo update-grub. It's possible I lost track and missed the winning configuration. I could always cause the problem to occur.

I may try finding a more recent BIOS. Perhaps it's that simple. If loading the new BIOS doesn't crash my system. ;-)

[XiFu (xifu)]

I was confused too, Ranxerox, but just the lines with ## are real comments, lines with a single # are used by the interpreter.

So the procedure that worked for me (ThinkPad X31) is this:

1. Backup "/boot/grub/menu.lst"

2. Open "/boot/grub/menu.lst" in an editor ("sudo gedit /boot/grub/menu.lst")

3. Change the line "# defoptions=quiet splash" to "# defoptions=quiet splash acpi_sleep=s4_nohwsig". These are the default options for each kernel in the boot menu.

4. Run "sudo update-grub"

5. Reboot and test

I would not advise to update the BIOS, because, as for me, my wifi-card would not work anymore (my BIOS is hacked, because IBM implemented a whitelist in the BIOS, so only som wifi-cards are working).

[Ranxerox (software-doorways)]

OK, so that's basically what I ended up with. Since then the instances of hibernate lockup have diminished. Not completely gone but better. So thanks for the tip.

I haven't gone looking for the BIOS yet. The T42 has a built-in wi-fi unit so your sad tale might not apply. Still, it's a last resort for sure. ;-)

[Radomír Černoch (radomir-cernoch)]

Rodrigo, do you have any peripherals attached during the suspend/resume? USB, PCMCIA, external display, ...

[Rodrigo Daunoravicius (rodelrod)]

Without 'acpi_sleep=s4_nohwsig':

Resume from hibernate always fails if the AC power is unplugged at any point, even if no periferals are attached, wether or not there is a battery in the unit.

With 'acpi_sleep=s4_nohwsig':

Resume works even if AC power is unplugged but (this I found later) there is one case where resume from both suspend and hibernate fail: when I resume/hibernate while docked, it won't resume after undocked, wether or not there is a battery on the unit and wether or not there are any peripherals (one external monitor, network, AC power) attached to the UltraDock. The reverse case works fine, I can hibernate/suspend while undocked and resume once docked.

For now I settled for setting 'acpi_sleep=s4_nohwsig' and keeping a battery on the unit at all times, even when docked, so that I don't have to hibernate it to undock it. In previous experience, keeping Li-ion batteries on laptos while working 10-12 hour workdays plugged into AC has tended to burn my batteries in less than six months, but this one seems to be holding out OK.

[Rjw-novell (rjw-novell)]

(In reply to comment #43)
> Without 'acpi_sleep=s4_nohwsig':
>
> Resume from hibernate always fails if the AC power is unplugged at any point,
> even if no periferals are attached, wether or not there is a battery in the
> unit.
>
> With 'acpi_sleep=s4_nohwsig':
>
> Resume works even if AC power is unplugged but (this I found later) there is
> one case where resume from both suspend and hibernate fail: when I
> resume/hibernate while docked, it won't resume after undocked, wether or not
> there is a battery on the unit and wether or not there are any peripherals (one
> external monitor, network, AC power) attached to the UltraDock. The reverse
> case works fine, I can hibernate/suspend while undocked and resume once docked.

I think this is an upstream bug. To verify this you can test the kernel from ftp://ftp.suse.com/pub/projects/kernel/kotd/HEAD/ (ie. 2.6.29-rc7+).

[apotonick (apotonick)]

i HAD the same problem with intrepid 2.6.27-11-generic and a x31.
after setting the boot parameter from XiFu at https://bugs.launchpad.net/linux/+bug/282220/comments/17 my x31 is able to hibernate. thanks for the directions!

[apotonick (apotonick)]

well it works until i plug in my wifi pcmcia card, a D-Link DWL-G630. when it's plugged in, neither hibernate nor suspend works and the x31 hangs. here are the steps to make it work again:

- since ubuntu uses the gnome-power-manager subsystem you have to configure it to unload the respective modules
- edit or create the file /etc/pm/config.d/modules
- add the line
  SUSPEND_MODULES="rt61pci"

and your hibernate/suspend should work (most of the time).

[Ulrich Hobelmann (u-hobelmann)]

Changing the grub kernel parameters works for me, too. Thanks XiFu!

[Paul Broadhead (pjbroad)]

I've just noticed that this bug has been changed to incomplete. May I ask what further information is requested? I think most people (myself included with an X31) have successfully used the work-around suggested.

[AceLan Kao (acelankao)]

Although, there is a workaround, it would be better to be confirmed that this problem is not happened in the latest release. I close this problem for now, please reopen if this is still an issue in the current Ubuntu release, Jaunty Jackalope 9.04 - http://www.ubuntu.com/getubuntu/download. If the issue remains in Jaunty, please test the latest upstream kernel build - https://wiki.ubuntu.com/KernelMainlineBuilds . To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[Desnacked (desnacked)]

My greetings,

https://bugs.gentoo.org/show_bug.cgi?id=257095 is a bug report on Gentoo's bugzilla dealing with this issue.

Disabling the hardware signature comparison would work alright on 2.6.28 kernels, but the problem reappeared with 2.6.30.
If you take a look at the bug report, on 2.6.30 there were not any messages complaining about "hardware changes" and s4_nohwsig did absolutely nothing.

It would be nice if someone with a defective Thinkpad could try a 2.6.30 kernel and see if s4_nohwsig works alright there too. If that's the case then the Gentoo bug report is most probably not related to this issue for 2.6.30 kernels.

Thank you : )

[Christian-lepper (christian-lepper)]

Hello,

I find the same behaviour as Comment #43 on my desktop machine running 11.3, fresh install. Whenever I unplug the machine after suspending, it will no more resume.

Only the kernel option 'acpi_sleep=s4_nohwsig' will allow for proper resuming.

BTW I had the same problem with 11.1, without having found a solution at the time, Cf. https://bugzilla.novell.com/show_bug.cgi?id=469962

For the moment I am happy to have a solution which works (for me), even though it should work out of the box.

This is a HP Pavilion with a nVidia Corporation MCP51 Motherboard, AMD Athlon64 X2 Dual Core Processor 3800+. Any more infos required ?

[Jslaby (jslaby)]

Should this still be needinfo?

[Rjw-novell (rjw-novell)]

Well, we can put the Christian's machine into the suspend blacklist if the
problem is still there in the master branch.

@Christian: Can you please test if the kernel from

http://ftp.suse.com/pub/projects/kernel/kotd/master/

(matching your system configuration) still has the problem?

If it does, please attach the output of dmidecode for your machine.

[Christian-lepper (christian-lepper)]

I gave a quick shot at this kernel, but it won't even boot. When I chose this kernel in the grub menu, after hitting enter the screen just goes blank - hard lock (even CAPSLOCK is not working anymore).

But in trying, I found out that the latest Kernel from updates (2.6.34.7-0.7-desktop) doesn't need anymore the acpi_sleep=s4_nohwsig option but will hibernate just fine.

So with regard to 11.3, please consider my remark as solved.

[Rjw-novell (rjw-novell)]

Thanks, marking as resolved.

[Novel-d (novel-d)]

I wanted to add that I faced the exact same issue with Dell Latitude E7440 (4th generation intel laptop) which is known to have very good compatibility with Linux, I have updated my bios(currently at A07) and the kernel but the problem persisted.

I am using opensuse 13.1 and the kernel from Kernel:stable which is currently 3.13.7-1-desktop and suspend to disk used to work only occassionally, after adding the kernel parameter and restarting it seems to work 100% of the time.