The reporter had got a "PM: Swap header not found" error at the last phase of
write to swap during swap space validation done after swsusp_write or
checkpoint of the snapshotted pages to swap. Turns out that for swap files, a
last step of specifying resume_offset is required for the sanity check to work
on the swap resume block that checks for the swap signature.
Just pasting my last email exchange for the sake of state completion of the
closed/invalid BUG:
===========================================================================
Worked almost fine as all pages were flushed to the swap file but last
phase bailed out as can be seen here:
[57001.487129] PM: Wrote 818356 kbytes in 13.04 seconds (62.75 MB/s)
[57001.488557] PM: S
[57001.511220] PM: Swap header not found!
It wrote 818 MB to the swap file but at the last phase, it bailed out in
swap_writer_finish function on a swap sanity check of the header
After writing the image to swap, swsusp_write calls swap_writer_finish to flush
the pages. But it also does an additional sanity check:
mark_swapfiles: (called by swap_writer_finish)
hib_bio_read_page(swsusp_resume_block, swsusp_header, NULL);
if (!memcmp("SWAP-SPACE",swsusp_header->sig, 10) ||
!memcmp("SWAPSPACE2",swsusp_header->sig, 10)) {
memcpy(swsusp_header->orig_sig,swsusp_header->sig, 10);
memcpy(swsusp_header->sig,SWSUSP_SIG, 10);
swsusp_header->image = handle->first_sector;
swsusp_header->flags = flags;
error = hib_bio_write_page(swsusp_resume_block,
swsusp_header, NULL);
} else {
printk(KERN_ERR "PM: Swap header not found!\n");
error = -ENODEV;
}
====================================
So it checks if the swsusp_resume_block which is actually the resume_offset of
the resume or swap device contains the swap signature or not.
For the case of a swap partition or device, its already set fine since the
resume block would be the start of the partition. (0)
But for the swap file which is contained in a partition, you have to
specify the resume_offset. Or in other words, you have to provision the
swap file as the swap for your system with the resume_offset set (resume
UUID matches the device or partition on which swap file is hosted)
Now to be honest, I never completed the full hibernate cycle on my 4 GB
ram laptop with a 8 gig swap file as the write to swap was going on for
over 30 mins! I didn't have patience to continue till the last phase and
see the Swap header failure and I thought you would also not try the
useless hibernate :)
But now that you have, you are doing fine with the swap file but only
that you miss the additional resume_offset provisioning for the swap
file.
This is done with filefrag -v. I won't waste time here but there is
already a post in the Ubuntu forum which highlights this step in using
the swap file as a partition. Its pretty neat and clean and also updates
grub (without you hand-editing grub with the resume=UUID=<>
resume_offset=<> line during boot and updates the ramdisk and grub
itself and modifies /etc/fstab to use the swap file (as expected) as the
swap target that can be hibernated (to overcome the swap_writer_finish
which I found in the code unfortunately done after the snashotted pages
were written to the swap file by the kernel. According to me, this
sanity check should have been done before the write to the swap in
swsusp_write to avoid the useless wait times for failure during
hibernate). But a hackish way can also enable this or set the resume
offset later and try resuming from the written swap file.
But you can just follow the procedure in the Ubuntu forum here to set
the resume_offset to the swap file while trying to treat it as a
hibernation target to avoid the last step failure mentioned above using
filefrag to get the offset to set with the UUID of the partition on
which the swap file resides fetched with blkid -g
http://ubuntuforums.org/showthread.php?t=1042946
(start from filefrag -v and blkid -g step to fetch resume_offset before
directly updating grub and /etc/fstab to update the swap target)
Regards,
-Karthick
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/844791
Title:
Hibernate returns to lock screen on a Lenovo T400 running Ubuntu 11.04
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/844791/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
