Bug 7057 - S4: fails when swap is mounted with loop device.
Summary: S4: fails when swap is mounted with loop device.
Status: REJECTED INVALID
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: i386 Linux
: P2 low
Assignee: Pavel Machek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-25 08:43 UTC by Thomas Steudten
Modified: 2006-09-27 01:31 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.17.7
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Thomas Steudten 2006-08-25 08:43:25 UTC
Most recent kernel where this bug did not occur: -
Distribution: FC5
Hardware Environment: x86, laptop samsung X20
Software Environment: kernel-2.6.17.7
Problem Description:

swap is active with loop device cipher like:

swapon -s
Filename                                Type            Size    Used    Priority
/dev/loop5                              partition       2056276 0       -1

/dev/loop5: [000f]:830 (/dev/hda5) offset=4096 encryption=AES128 multi-key-v3

Try to hibernate with echo disk > /sys/power/state fails with "no swap device".

The kernel should use the real device, when the loop device isn't the best.
Comment 1 Pavel Machek 2006-08-25 12:46:19 UTC
And why do you think it could work?

What does your /proc/cmdline look like?

Are you resuming from kernel, or from initrd?
Comment 2 Thomas Steudten 2006-08-26 01:39:21 UTC
Well, with /dev/hda (normal IDE block device) STD works. Running the system with
a loop device (/dev/loopX) as swap works too. Trying to STD (swsusp) with
platform methode and loop-device as only active swap, gives:
swap.c:printk(KERN_ERR "swsusp: Cannot find swap device, try swapon -a.\n");

This check is done in:
swap_type_of().

swsusp writes to the swap device, if there's enough space. So it doesn't matter,
what data is written there, it writes to the free space on the swap device.
So why can't the kernel do this, when there's only a loop device as active swap?

losetup -a gives the block device info (/dev/hda5) which matches to the active
swap device (/dev/loop5). So the kernel has the information which block device
to use for swap. On the other hand a cmd-line "resume=/dev/hda5" is given.

So the kernel can do this:
1) query swap device
2) find a loop device as a active swap device
3) find out the matching block device for this loop device
4) [check this with resume=.. block device]
5) Use the block device for swsusp.
6) STD
7) resume from resume=..
8) ..

Why shouldn't this work?

I can do this by script, but the kernel should do this work.

I can write a patch for this, if you can't do this.
Comment 3 Pavel Machek 2006-08-26 03:13:29 UTC
Hi!

> Well, with /dev/hda (normal IDE block device) STD works. Running the system with
> a loop device (/dev/loopX) as swap works too. Trying to STD (swsusp) with
> platform methode and loop-device as only active swap, gives:
> swap.c:printk(KERN_ERR "swsusp: Cannot find swap device, try swapon -a.\n");
> 
> This check is done in:
> swap_type_of().
> 
> swsusp writes to the swap device, if there's enough space. So it doesn't matter,
> what data is written there, it writes to the free space on the swap device.
> So why can't the kernel do this, when there's only a loop device as active swap?

Because that would be layering violation.

> losetup -a gives the block device info (/dev/hda5) which matches to the active
> swap device (/dev/loop5). So the kernel has the information which block device
> to use for swap. On the other hand a cmd-line "resume=/dev/hda5" is
> given.

That's wrong, you suspended to loop5, and you want to resume from hda5.

> So the kernel can do this:
> 1) query swap device
> 2) find a loop device as a active swap device

Yes, kernel _can_ do this, but this would be layering violation.

> I can do this by script, but the kernel should do this work.
> 
> I can write a patch for this, if you can't do this.

Lets see what a patch looks like...

Anyway right solution is to use uswsusp (see uswsusp.sf.net), and only
attempt resume after loopbacks are set up.
								Pavel

Comment 4 Thomas Steudten 2006-08-26 04:54:35 UTC
> Because that would be layering violation.
That could be a reason ;-)

> That's wrong, you suspended to loop5, and you want to resume from hda5.
I tried to STD with running swap, because running swap device is a loop
device, the swsusp complains, that there's no swap device:
swap.c:printk(KERN_ERR "swsusp: Cannot find swap device, try swapon -a.\n");
The user thinks, or well I find a swap device, see swapon -s - it's there..
I give the resume= cmd-line every time in the grub.conf file, so the kernel
complains too, that there's no resume device. There's no STD magic, that's
maybe true, so why complaining?
Does the kernel compare the resume= and the running swap device?
 
>Anyway right solution is to use uswsusp (see uswsusp.sf.net), and only
>attempt resume after loopbacks are set up.
								
This is overhead -  I swapoff the loop, swapon the hda5, STD, swapoff -a and
swapon -a. That's ok, but I think the kernel could do this for me.
This works, if there's enough swap space available for STD.

There could be a flag (/proc/../use_resume) that means, use the block device
given from resume=.. cmdline for STD, no matter what swap is running.
Comment 5 Pavel Machek 2006-08-26 05:23:12 UTC
> > That's wrong, you suspended to loop5, and you want to resume from hda5.
> I tried to STD with running swap, because running swap device is a loop
> device, the swsusp complains, that there's no swap device:
> swap.c:printk(KERN_ERR "swsusp: Cannot find swap device, try swapon -a.\n");
> The user thinks, or well I find a swap device, see swapon -s - it's there..
> I give the resume= cmd-line every time in the grub.conf file, so the kernel
> complains too, that there's no resume device. There's no STD magic, that's
> maybe true, so why complaining?
> Does the kernel compare the resume= and the running swap device?

Yes. Feel free to improve the messages or the documentation.

> >Anyway right solution is to use uswsusp (see uswsusp.sf.net), and only
> >attempt resume after loopbacks are set up.
> 								
> This is overhead -  I swapoff the loop, swapon the hda5, STD, swapoff -a and
> swapon -a. That's ok, but I think the kernel could do this for me.
> This works, if there's enough swap space available for STD.

No, kernel will not do this for you.

> There could be a flag (/proc/../use_resume) that means, use the block device
> given from resume=.. cmdline for STD, no matter what swap is running.

No.

Comment 6 Pavel Machek 2006-09-27 01:31:53 UTC
Kernel  will not second-guess the users.

Note You need to log in before you can comment on or make changes to this bug.