Bug 22732

the problem seems to be fix on 32bit kernel.
Here is what I did:
1. boot into bash
2. mkswap /dev/sdaX
3. swapon -a shows the swap partition is probed successfully
4. reboot
In 32bit kernel, hibernate starts to work.
In x86_64 kernel, kernel can find swap partition, until it tried to hibernate, i.e. system suspends okay, but reboots instead of resume from disk, and kernel fails to probe the swap partition after reboot.

I cannot reproduce this issue.

It looks like your resume kernel is different from the hibernated kernel.
Please verify that this isn't the case.

When exactly does the reboot happen when you're trying to resume?

Also, do you use the built-in hibernation or s2disk?

(In reply to comment #2)
> I cannot reproduce this issue.
> 
> It looks like your resume kernel is different from the hibernated kernel.
> Please verify that this isn't the case.
> 
No, hibernate and resume in the same kernel.

> When exactly does the reboot happen when you're trying to resume?
> 
it hibernate normally. But this step seems break the swap partition.
And when I press power button to resume, kernel fails to find swap partition, thus it boots up normally instead of resume.

> Also, do you use the built-in hibernation or s2disk?

I run "echo disk > /sys/power/state" to hibernate.

I made a double check and the hibernation works well in 2.6.36-rc8 and breaks in 2.6.36.

Hmm.  There were no changes in kernel/power/ between .36-rc8 and .36.  Moreover,
there's only one x86 change related to KVM from that time.

Any chance to bisect?

Hi,

same issue here. Hibernation works with 2.6.36-rc8 kernel ant does not work with further kernels (x86_64). I'm currently trying to bisect (bad= v2.6.37-rc1 good= v2.6.36-rc8) : long task...

A noticeable think; with working kernels, i have the following message when trying to hibernate :
 PM: Creating hibernation image:

and not with non-working kernels...

bisect result =>
[root@strange linux-2.6]# git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[3624eb04c24861ab296842414f9752a393e68372] PM / Hibernate: Modify signature used to mark swap

What kind of user space do you have?

Mostly fedora 14 (with customised env., like kernel)

Is your resume kernel (ie. the one used for reading the image) the same
as your hibernated kernel?  Please double check.

Also please let me know what your kernel command line is.

I double check at every step of git bisect process; no doubt (git bisect: compile kernel: reboot: try hibernate: git bisect: compile: reboot: try hibernate, etc...)

[    0.000000] Command line: ro root=UUID=3354f340-fc60-4b71-aad8-3eefb1c5dfa1 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=fr-latin9 rhgb quiet selinux=0 init=/sbin/bootchartd
[

OK, so Fedora seems to do some tricks in initramfs to feed the kernel with
the image location and doesn't find it due to a different signature.

I'll post a patch that will change the signature back to the old one for
2.6.37, but I'd like to make sure I know what the problem is.

Which one is your resume partition?

Created attachment 39862 [details]
init from initrd

my init from initrd

>> Which one is your resume partition?
/dev/sda5 a plain sw

sorry ! no way to edit previous comments ... 

So swap partition is a plain partition :
[root@strange img]# swapon -s
Filename				Type		Size	Used	Priority
/dev/sda5                               partition	3481596	0	-1

Does resume from hibernation work if you add resume=/dev/sda5 to the kernel
command line?

You are right : with "resume=/dev/sda5" in the command line, my genuine 2.6.37.rc5 don't mess hibernate; works as expected...

OK, thanks for verifying.

The patch to restore the old signature is at:
https://patchwork.kernel.org/patch/400092/

Patch : https://patchwork.kernel.org/patch/400092/
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>

Thanks to you for your quickness ;-)

Unfortunately I did not see the original patch or I would have NAK'ed it anyway ;)

The suspend signature is IMHO one of the kernel interfaces that need to go through feature-removal.txt to get changed, as hopefully every distribution has some kind of "remove unresumed image in case of normal boot"-tool which needs to know the signature.

Stuff like versioning the suspend image needs probably an extra field in the suspend header.

Fixed by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=be8cd644c49dca4212e975455c8e7119b848ebe8 .