[RFC][PATCH] swsusp: warn about USB devices in documentation

[RFC][PATCH] swsusp: warn about USB devices in documentation

[Rafael J. Wysocki]

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]

Hi,

The appended patch contains a warning about the possiblity to lose data
if any filesystems on USB devices are mounted before suspend.

The A:-Q: part is from my correspondence with Alan Stern (thanks Alan).

Greetings,
Rafael


Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 Documentation/power/swsusp.txt |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+)

Index: linux-2.6.16-rc3-mm1/Documentation/power/swsusp.txt
===================================================================
--- linux-2.6.16-rc3-mm1.orig/Documentation/power/swsusp.txt
+++ linux-2.6.16-rc3-mm1/Documentation/power/swsusp.txt
@@ -17,6 +17,11 @@ Some warnings, first.
  * but it will probably only crash.
  *
  * (*) suspend/resume support is needed to make it safe.
+ *
+ * If you have any filesystems on USB devices mounted before suspend,
+ * they won't be mounted after resume and you may lose data, as though
+ * you have unplugged the USB devices with mounted filesystems on them
+ * (see the FAQ below for details).
 
 You need to append resume=/dev/your_swap_partition to kernel command
 line. Then you suspend by
@@ -347,3 +352,22 @@ terminal the kernel switches to during s
 kernel console loglevel to at least 5, for example by doing
 
 	echo 5 > /proc/sys/kernel/printk
+
+Q: Is this true that if I have a mounted filesystem on a USB device and
+I suspend to disk, I can lose data unless the filesystem has been mounted
+with "sync"?
+
+A: That's right.  It depends on your hardware, and it could be true even for
+suspend-to-RAM. In fact, even with "-o sync" you can lose data if your
+programs have information in buffers they haven't written out to disk.
+
+If you're lucky, your hardware will support low-power modes for USB
+controllers while the system is asleep.  Lots of hardware doesn't,
+however.  Shutting off the power to a USB controller is equivalent to 
+unplugging all the attached devices.
+
+Remember that it's always a bad idea to unplug a disk drive containing a
+mounted filesystem.  With USB that's true even when your system is asleep!
+The safest thing is to unmount all USB-based filesystems before suspending 
+and remount them after resuming.
+

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

On Ne 19-02-06 23:06:23, Rafael J. Wysocki wrote:
> Hi,
> 
> The appended patch contains a warning about the possiblity to lose data
> if any filesystems on USB devices are mounted before suspend.
> 
> The A:-Q: part is from my correspondence with Alan Stern (thanks
Alan).

ACK.

-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1505 bytes --]

On Sun, 19 Feb 2006, Rafael J. Wysocki wrote:

> Hi,
> 
> The appended patch contains a warning about the possiblity to lose data
> if any filesystems on USB devices are mounted before suspend.
> 
> The A:-Q: part is from my correspondence with Alan Stern (thanks Alan).

> --- linux-2.6.16-rc3-mm1.orig/Documentation/power/swsusp.txt
> +++ linux-2.6.16-rc3-mm1/Documentation/power/swsusp.txt
> @@ -17,6 +17,11 @@ Some warnings, first.
>   * but it will probably only crash.
>   *
>   * (*) suspend/resume support is needed to make it safe.
> + *
> + * If you have any filesystems on USB devices mounted before suspend,
> + * they won't be mounted after resume and you may lose data, as though
> + * you have unplugged the USB devices with mounted filesystems on them
> + * (see the FAQ below for details).

This isn't quite right.  The filesystems _will_ still be mounted, but 
inaccessible (as though you have unplugged the USB devices with mounted 
filesystems on them).

Furthermore, this may or may not happen depending on your hardware and the
type of suspend.  So the "you _may_ lose data" part is good... but the
"they _won't_ be mounted" part is bad.  On some types of machines (I've
heard that Apple laptops work well) the process is very reliable; so long 
as the battery doesn't discharge entirely -- and provided you don't 
actually unplug the device while the machine is asleep -- you can resume 
safely with filesystems intact.

Can you update the patch to fix this paragraph?

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]

Hi!

> > The appended patch contains a warning about the possiblity to lose data
> > if any filesystems on USB devices are mounted before suspend.
> > 
> > The A:-Q: part is from my correspondence with Alan Stern (thanks Alan).
> 
> > --- linux-2.6.16-rc3-mm1.orig/Documentation/power/swsusp.txt
> > +++ linux-2.6.16-rc3-mm1/Documentation/power/swsusp.txt
> > @@ -17,6 +17,11 @@ Some warnings, first.
> >   * but it will probably only crash.
> >   *
> >   * (*) suspend/resume support is needed to make it safe.
> > + *
> > + * If you have any filesystems on USB devices mounted before suspend,
> > + * they won't be mounted after resume and you may lose data, as though
> > + * you have unplugged the USB devices with mounted filesystems on them
> > + * (see the FAQ below for details).
> 
> This isn't quite right.  The filesystems _will_ still be mounted, but 
> inaccessible (as though you have unplugged the USB devices with mounted 
> filesystems on them).
> 
> Furthermore, this may or may not happen depending on your hardware and the
> type of suspend.  So the "you _may_ lose data" part is good... but the
> "they _won't_ be mounted" part is bad.  On some types of machines (I've
> heard that Apple laptops work well) the process is very reliable; so long 
> as the battery doesn't discharge entirely -- and provided you don't 
> actually unplug the device while the machine is asleep -- you can resume 
> safely with filesystems intact.
> 
> Can you update the patch to fix this paragraph?

Well, this is talking about suspend-to-disk... That is expected to
power down machine, without providing USB bus power. If box
suspends-to-disk and leaves USB up, something is wrong with the
machine.
								Pavel
-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Rafael J. Wysocki]

Hi,

On Monday 20 February 2006 04:50, Alan Stern wrote:
> On Sun, 19 Feb 2006, Rafael J. Wysocki wrote:
> > The appended patch contains a warning about the possiblity to lose data
> > if any filesystems on USB devices are mounted before suspend.
> > 
> > The A:-Q: part is from my correspondence with Alan Stern (thanks Alan).
> 
> > --- linux-2.6.16-rc3-mm1.orig/Documentation/power/swsusp.txt
> > +++ linux-2.6.16-rc3-mm1/Documentation/power/swsusp.txt
> > @@ -17,6 +17,11 @@ Some warnings, first.
> >   * but it will probably only crash.
> >   *
> >   * (*) suspend/resume support is needed to make it safe.
> > + *
> > + * If you have any filesystems on USB devices mounted before suspend,
> > + * they won't be mounted after resume and you may lose data, as though
> > + * you have unplugged the USB devices with mounted filesystems on them
> > + * (see the FAQ below for details).
> 
> This isn't quite right.  The filesystems _will_ still be mounted, but 
> inaccessible (as though you have unplugged the USB devices with mounted 
> filesystems on them).
> 
> Furthermore, this may or may not happen depending on your hardware and the
> type of suspend.  So the "you _may_ lose data" part is good... but the
> "they _won't_ be mounted" part is bad.  On some types of machines (I've
> heard that Apple laptops work well) the process is very reliable; so long 
> as the battery doesn't discharge entirely -- and provided you don't 
> actually unplug the device while the machine is asleep -- you can resume 
> safely with filesystems intact.
> 
> Can you update the patch to fix this paragraph?

Sure, I will.

[I should have waited a bit longer before I posted it to Andrew.]

Greetings,
Rafael

Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Rafael J. Wysocki]

Hi,

On Monday 20 February 2006 11:34, Pavel Machek wrote:
> > > The appended patch contains a warning about the possiblity to lose data
> > > if any filesystems on USB devices are mounted before suspend.
> > > 
> > > The A:-Q: part is from my correspondence with Alan Stern (thanks Alan).
> > 
> > > --- linux-2.6.16-rc3-mm1.orig/Documentation/power/swsusp.txt
> > > +++ linux-2.6.16-rc3-mm1/Documentation/power/swsusp.txt
> > > @@ -17,6 +17,11 @@ Some warnings, first.
> > >   * but it will probably only crash.
> > >   *
> > >   * (*) suspend/resume support is needed to make it safe.
> > > + *
> > > + * If you have any filesystems on USB devices mounted before suspend,
> > > + * they won't be mounted after resume and you may lose data, as though
> > > + * you have unplugged the USB devices with mounted filesystems on them
> > > + * (see the FAQ below for details).
> > 
> > This isn't quite right.  The filesystems _will_ still be mounted, but 
> > inaccessible (as though you have unplugged the USB devices with mounted 
> > filesystems on them).
> > 
> > Furthermore, this may or may not happen depending on your hardware and the
> > type of suspend.  So the "you _may_ lose data" part is good... but the
> > "they _won't_ be mounted" part is bad.  On some types of machines (I've
> > heard that Apple laptops work well) the process is very reliable; so long 
> > as the battery doesn't discharge entirely -- and provided you don't 
> > actually unplug the device while the machine is asleep -- you can resume 
> > safely with filesystems intact.
> > 
> > Can you update the patch to fix this paragraph?
> 
> Well, this is talking about suspend-to-disk... That is expected to
> power down machine, without providing USB bus power. If box
> suspends-to-disk and leaves USB up, something is wrong with the
> machine.

Still the filesystems will in fact be mounted but inaccessible.  Perhaps we
should replace "they won't be mounted after resume" with
"they won't be accessible after resume".  Would that be right Alan?

Rafael

Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1081 bytes --]

On Mon, 20 Feb 2006, Pavel Machek wrote:

> > Can you update the patch to fix this paragraph?
> 
> Well, this is talking about suspend-to-disk... That is expected to
> power down machine, without providing USB bus power. If box
> suspends-to-disk and leaves USB up, something is wrong with the
> machine.

Oh, sorry, I didn't realize that.

Isn't there an ACPI mode that powers down most things (including RAM) but
is able to respond to wakeup events?  I can't remember the mode's name,
except that it's almost certainly "S" followed by some meaningless number
followed by some unhelpful word. :-)  Since USB plug/unplug is potentially
a wakeup event, such a mode must provide suspend power to the USB
controller.

Does swsusp still support these not-completely-powered-off modes?

On Mon, 20 Feb 2006, Rafael J. Wysocki wrote:

> Still the filesystems will in fact be mounted but inaccessible.  Perhaps we
> should replace "they won't be mounted after resume" with
> "they won't be accessible after resume".  Would that be right Alan?

Yes, it would be a lot better.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

Hi!
> > > Can you update the patch to fix this paragraph?
> > 
> > Well, this is talking about suspend-to-disk... That is expected to
> > power down machine, without providing USB bus power. If box
> > suspends-to-disk and leaves USB up, something is wrong with the
> > machine.
> 
> Oh, sorry, I didn't realize that.
> 
> Isn't there an ACPI mode that powers down most things (including RAM) but
> is able to respond to wakeup events?  I can't remember the mode's name,
> except that it's almost certainly "S" followed by some meaningless number
> followed by some unhelpful word. :-)  Since USB plug/unplug is potentially
> a wakeup event, such a mode must provide suspend power to the USB
> controller.

Maybe S4 does that, but I'm not sure...

> Does swsusp still support these not-completely-powered-off modes?

Yes. echo platform > /sys/power/disk.
								Pavel
-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1079 bytes --]

On Mon, 20 Feb 2006, Pavel Machek wrote:

> Hi!
> > > > Can you update the patch to fix this paragraph?
> > > 
> > > Well, this is talking about suspend-to-disk... That is expected to
> > > power down machine, without providing USB bus power. If box
> > > suspends-to-disk and leaves USB up, something is wrong with the
> > > machine.
> > 
> > Oh, sorry, I didn't realize that.
> > 
> > Isn't there an ACPI mode that powers down most things (including RAM) but
> > is able to respond to wakeup events?  I can't remember the mode's name,
> > except that it's almost certainly "S" followed by some meaningless number
> > followed by some unhelpful word. :-)  Since USB plug/unplug is potentially
> > a wakeup event, such a mode must provide suspend power to the USB
> > controller.
> 
> Maybe S4 does that, but I'm not sure...
> 
> > Does swsusp still support these not-completely-powered-off modes?
> 
> Yes. echo platform > /sys/power/disk.

So if you did that, you could suspend-to-disk while leaving USB up, right?  
Without anything being wrong with the machine.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

On Po 20-02-06 11:41:49, Alan Stern wrote:
> On Mon, 20 Feb 2006, Pavel Machek wrote:
> 
> > Hi!
> > > > > Can you update the patch to fix this paragraph?
> > > > 
> > > > Well, this is talking about suspend-to-disk... That is expected to
> > > > power down machine, without providing USB bus power. If box
> > > > suspends-to-disk and leaves USB up, something is wrong with the
> > > > machine.
> > > 
> > > Oh, sorry, I didn't realize that.
> > > 
> > > Isn't there an ACPI mode that powers down most things (including RAM) but
> > > is able to respond to wakeup events?  I can't remember the mode's name,
> > > except that it's almost certainly "S" followed by some meaningless number
> > > followed by some unhelpful word. :-)  Since USB plug/unplug is potentially
> > > a wakeup event, such a mode must provide suspend power to the USB
> > > controller.
> > 
> > Maybe S4 does that, but I'm not sure...
> > 
> > > Does swsusp still support these not-completely-powered-off modes?
> > 
> > Yes. echo platform > /sys/power/disk.
> 
> So if you did that, you could suspend-to-disk while leaving USB up, right?  
> Without anything being wrong with the machine.

Not sure... never seen such machine. My impression is that USB needs
more power than RAMs in self-refresh mode...

You are right that maybe some machines where USB has power in S4
exist.. I never seen one.
								Pavel
-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1519 bytes --]


On Mon, 20 Feb 2006, Alan Stern wrote:

> On Mon, 20 Feb 2006, Pavel Machek wrote:
>
> > Hi!
> > > > > Can you update the patch to fix this paragraph?
> > > >
> > > > Well, this is talking about suspend-to-disk... That is expected to
> > > > power down machine, without providing USB bus power. If box
> > > > suspends-to-disk and leaves USB up, something is wrong with the
> > > > machine.
> > >
> > > Oh, sorry, I didn't realize that.
> > >
> > > Isn't there an ACPI mode that powers down most things (including RAM) but
> > > is able to respond to wakeup events?  I can't remember the mode's name,
> > > except that it's almost certainly "S" followed by some meaningless number
> > > followed by some unhelpful word. :-)  Since USB plug/unplug is potentially
> > > a wakeup event, such a mode must provide suspend power to the USB
> > > controller.
> >
> > Maybe S4 does that, but I'm not sure...
> >
> > > Does swsusp still support these not-completely-powered-off modes?
> >
> > Yes. echo platform > /sys/power/disk.
>
> So if you did that, you could suspend-to-disk while leaving USB up, right?
> Without anything being wrong with the machine.

No, not likely. S4 is +/- equivalent to a "soft off", except that it
responds to more wake-up events than a soft off will (which BTW is defined
as "S5").

Even S3 will power down all of the PCI buses, including the USB host
controllers. The chances of having any low-power system state that will
still power the USB ports (by design) is pretty slim.

Thanks,


	Pat


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2174 bytes --]

On Mon, 20 Feb 2006, Patrick Mochel wrote:

> > > > Does swsusp still support these not-completely-powered-off modes?
> > >
> > > Yes. echo platform > /sys/power/disk.
> >
> > So if you did that, you could suspend-to-disk while leaving USB up, right?
> > Without anything being wrong with the machine.
> 
> No, not likely. S4 is +/- equivalent to a "soft off", except that it
> responds to more wake-up events than a soft off will (which BTW is defined
> as "S5").

Does it respond to USB wakeup events (like plugging in a new device)?

> Even S3 will power down all of the PCI buses, including the USB host
> controllers. The chances of having any low-power system state that will
> still power the USB ports (by design) is pretty slim.

Here is a counterexample from Kyle Moffet 
(<http://marc.theaimsgroup.com/?l=linux-kernel&m=113980955219914&w=2>):

	Let me bring up the example of my PowerBook again.  It's RAM is
	fully powered right now, running from battery, and it has another
	couple days of sleep- charge left before I have to worry about
	plugging it in again.  When I open it, the firmware automatically
	powers up the CPU and other hardware and returns control to the
	OS.  I can _also_ trigger it to wake by leaving it closed and
	connecting an external VGA and USB (it wakes every time I connect
	a USB, but my suspend script puts it to sleep again if it's closed
	and has no external VGA).

There's a difference between powering-down and turning off completely.  
The USB suspend-power-budget per attached port is 500 uA at 5 V, which
amounts to 2.5 mW.  While that's more than you need to keep RAM alive,
it's not a tremendous amount.  And most devices probably use less power
when suspended than this maximum.

The EHCI specification includes a lot of very careful language about which
portions of the controller should be attached to which power well.  It's
quite clear that most of the controller's circuitry can be turned off
while still supplying enough suspend power to keep the bus alive and
enable wakeup events.

And if the computer can wake up in response to USB events, then obviously
the USB controller _is_ receiving some power.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3063 bytes --]


On Mon, 20 Feb 2006, Alan Stern wrote:

> On Mon, 20 Feb 2006, Patrick Mochel wrote:
>
> > > > > Does swsusp still support these not-completely-powered-off modes?
> > > >
> > > > Yes. echo platform > /sys/power/disk.
> > >
> > > So if you did that, you could suspend-to-disk while leaving USB up, right?
> > > Without anything being wrong with the machine.
> >
> > No, not likely. S4 is +/- equivalent to a "soft off", except that it
> > responds to more wake-up events than a soft off will (which BTW is defined
> > as "S5").
>
> Does it respond to USB wakeup events (like plugging in a new device)?

It depends on the platform - whether or not they provide any power at all,
and whether or not they implemented the GPE plumbing for it.

> > Even S3 will power down all of the PCI buses, including the USB host
> > controllers. The chances of having any low-power system state that will
> > still power the USB ports (by design) is pretty slim.
>
> Here is a counterexample from Kyle Moffet
> (<http://marc.theaimsgroup.com/?l=linux-kernel&m=113980955219914&w=2>):
>
> 	Let me bring up the example of my PowerBook again.  It's RAM is
> 	fully powered right now, running from battery, and it has another
> 	couple days of sleep- charge left before I have to worry about
> 	plugging it in again.  When I open it, the firmware automatically
> 	powers up the CPU and other hardware and returns control to the
> 	OS.  I can _also_ trigger it to wake by leaving it closed and
> 	connecting an external VGA and USB (it wakes every time I connect
> 	a USB, but my suspend script puts it to sleep again if it's closed
> 	and has no external VGA).

No surpirse there - that's the behavior most would expect, and Apple seems
pretty good about implementing things along those lines.

> There's a difference between powering-down and turning off completely.
> The USB suspend-power-budget per attached port is 500 uA at 5 V, which
> amounts to 2.5 mW.  While that's more than you need to keep RAM alive,
> it's not a tremendous amount.  And most devices probably use less power
> when suspended than this maximum.
>
> The EHCI specification includes a lot of very careful language about which
> portions of the controller should be attached to which power well.  It's
> quite clear that most of the controller's circuitry can be turned off
> while still supplying enough suspend power to keep the bus alive and
> enable wakeup events.
>
> And if the computer can wake up in response to USB events, then obviously
> the USB controller _is_ receiving some power.

True, and I apologize if I misunderstood your initial question. By "up", I
thought you meant fully powered and functional.

But yes, the USB ports may receive enough power to recognize a wakeup plug
event, but it does ultimately depend on the platform and what they choose
to implement.

On x86 platforms, ther is no definitive answer. The ACPI spec mentions it
(section A.2.5), but does not require it. Windows might require that
feature, and if they do, that will make it more common on x86 platforms..


	Pat

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 942 bytes --]

On Mon, 20 Feb 2006, Patrick Mochel wrote:

> > And if the computer can wake up in response to USB events, then obviously
> > the USB controller _is_ receiving some power.
> 
> True, and I apologize if I misunderstood your initial question. By "up", I
> thought you meant fully powered and functional.

No; in the context of this thread I merely meant suspend-power was
present.  Pavel had said that a machine which supplies any USB power at
all during swsusp is broken.  I was trying to show this isn't so.

> But yes, the USB ports may receive enough power to recognize a wakeup plug
> event, but it does ultimately depend on the platform and what they choose
> to implement.
> 
> On x86 platforms, ther is no definitive answer. The ACPI spec mentions it
> (section A.2.5), but does not require it. Windows might require that
> feature, and if they do, that will make it more common on x86 platforms..

We can but hope...  :-)

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: [RFC][PATCH] swsusp: warn about USB devices in documentation

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On Po 20-02-06 15:30:16, Alan Stern wrote:
> On Mon, 20 Feb 2006, Patrick Mochel wrote:
> 
> > > And if the computer can wake up in response to USB events, then obviously
> > > the USB controller _is_ receiving some power.
> > 
> > True, and I apologize if I misunderstood your initial question. By "up", I
> > thought you meant fully powered and functional.
> 
> No; in the context of this thread I merely meant suspend-power was
> present.  Pavel had said that a machine which supplies any USB power at
> all during swsusp is broken.  I was trying to show this isn't so.

I take that back. I still claim it is unusal ;-).
								Pavel
-- 
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]