USB: on suspend to ram/disk all usb devices are replugged

USB: on suspend to ram/disk all usb devices are replugged

[Maxim Levitsky]

Hi,
	I noticed that after suspend/resume cycle all my usb devices are unplugged/replugged by uhci driver.
While it is not that big problem to me, that can be a real problem if a device is a flash card with mounted 
file-system, because disappeared device will cause file-system corruption.

I found why this happens.

drivers/usb/host/pci-quirks.c:uhci_check_and_reset_hc checks that the BIOS didn't play with USB controller, and on my system
with or without a USB Legacy support turned on in the BIOS, the BIOS does meddle with USB controller,

But I suggest adding a option that will allow the user to bypass that check, because for example on my system USB works perfectly
if I disable the checks that this function does (but I agree that those checks are  very valuable, since I almost sure that on many systems USB
won't work without resetting the USB controller.)

Secondary,  this function checks for UHCI_USBCMD_CONFIGURE, that is not set on resume,
According to both UHCI and ICH8 documentation this is software only bit, but I didn't find any place in kernel where it is set,
(But such place exist, because reading from usb IO ports confirm that it is set during normal work, I will try to find it)

Disabling both check for UHCI_USBLEGSUP and UHCI_USBCMD_CONFIGURE makes all usb devices (I have mouse,keyborad, and joystick)
work fine on resume from ram without this "virtual" replugging.

Suspend to disk still causes "virtual replugging"  and I think that controller is reset and will unplug/replug devices anyway
Resolving this problem is very difficult. Maybe it possible to check on unplugging event that this caused by suspend  if the same device is
replugged then don't remove/reinstall driver, but this is very difficult to implement properly,
Maybe just refuse to suspend if some valuable device is connected (sorry if it is done this way already)

Also I want to note that I didn't yet checked any EHCI devices, because I don't have any (I am going to buy a usb stick soon)
But I feel that the above will be true for ehci too....

Looking for comments,
	Best regards,
		Maxim Levitsky

Re: USB: on suspend to ram/disk all usb devices are replugged

[Alan Stern]

On Tue, 27 Mar 2007, Maxim Levitsky wrote:

> Hi,
> 	I noticed that after suspend/resume cycle all my usb devices are unplugged/replugged by uhci driver.
> While it is not that big problem to me, that can be a real problem if a device is a flash card with mounted 
> file-system, because disappeared device will cause file-system corruption.
> 
> I found why this happens.
> 
> drivers/usb/host/pci-quirks.c:uhci_check_and_reset_hc checks that the BIOS didn't play with USB controller, and on my system
> with or without a USB Legacy support turned on in the BIOS, the BIOS does meddle with USB controller,
> 
> But I suggest adding a option that will allow the user to bypass that check, because for example on my system USB works perfectly
> if I disable the checks that this function does (but I agree that those checks are  very valuable, since I almost sure that on many systems USB
> won't work without resetting the USB controller.)

No.  It just isn't safe to do that.  If the BIOS has done something to the
controller then it may very well have reset the attached devices too.  Or
changed their addresses, or done something else equally drastic.

> Secondary,  this function checks for UHCI_USBCMD_CONFIGURE, that is not set on resume,
> According to both UHCI and ICH8 documentation this is software only bit, but I didn't find any place in kernel where it is set,
> (But such place exist, because reading from usb IO ports confirm that it is set during normal work, I will try to find it)

It is set in drivers/usb/host/uhci-hcd.c:start_rh().

> Disabling both check for UHCI_USBLEGSUP and UHCI_USBCMD_CONFIGURE makes all usb devices (I have mouse,keyborad, and joystick)
> work fine on resume from ram without this "virtual" replugging.

The UHCI specification is rather sparse in many respects, and it doesn't 
say what the host firmware should or should not do during a resume.  So 
the driver has to be very conservative and assume that any indication of a 
change means that the entire controller must be reset.

> Suspend to disk still causes "virtual replugging"  and I think that controller is reset and will unplug/replug devices anyway
> Resolving this problem is very difficult. Maybe it possible to check on unplugging event that this caused by suspend  if the same device is
> replugged then don't remove/reinstall driver, but this is very difficult to implement properly,
> Maybe just refuse to suspend if some valuable device is connected (sorry if it is done this way already)

Long ago I posted a patch that would take care of all this.  Not just for
UHCI, but for any USB controller.  Maybe I should dig it out, update it,
and submit it.

> Also I want to note that I didn't yet checked any EHCI devices, because I don't have any (I am going to buy a usb stick soon)
> But I feel that the above will be true for ehci too....

EHCI controllers tend to be better behaved than UHCI controllers, perhaps
because the specification is much more careful to explain what must be
done.  In many cases a computer can resume from suspend-to-RAM with all 
the EHCI-connected devices still intact.

Alan Stern

Re: USB: on suspend to ram/disk all usb devices are replugged

[Maxim]

On Tuesday 27 March 2007 19:15:14 Alan Stern wrote:
> On Tue, 27 Mar 2007, Maxim Levitsky wrote:
> 
> > Hi,
> > 	I noticed that after suspend/resume cycle all my usb devices are unplugged/replugged by uhci driver.
> > While it is not that big problem to me, that can be a real problem if a device is a flash card with mounted 
> > file-system, because disappeared device will cause file-system corruption.
> > 
> > I found why this happens.
> > 
> > drivers/usb/host/pci-quirks.c:uhci_check_and_reset_hc checks that the BIOS didn't play with USB controller, and on my system
> > with or without a USB Legacy support turned on in the BIOS, the BIOS does meddle with USB controller,
> > 
> > But I suggest adding a option that will allow the user to bypass that check, because for example on my system USB works perfectly
> > if I disable the checks that this function does (but I agree that those checks are  very valuable, since I almost sure that on many systems USB
> > won't work without resetting the USB controller.)
> 
> No.  It just isn't safe to do that.  If the BIOS has done something to the
> controller then it may very well have reset the attached devices too.  Or
> changed their addresses, or done something else equally drastic.

I agree, I was only saying a option to override this check, for users who know that this is not the case.

> 
> > Secondary,  this function checks for UHCI_USBCMD_CONFIGURE, that is not set on resume,
> > According to both UHCI and ICH8 documentation this is software only bit, but I didn't find any place in kernel where it is set,
> > (But such place exist, because reading from usb IO ports confirm that it is set during normal work, I will try to find it)
> 
> It is set in drivers/usb/host/uhci-hcd.c:start_rh().
Thanks a lot, it would take a lot of time to find that out to me,
> 
> > Disabling both check for UHCI_USBLEGSUP and UHCI_USBCMD_CONFIGURE makes all usb devices (I have mouse,keyborad, and joystick)
> > work fine on resume from ram without this "virtual" replugging.
> 
> The UHCI specification is rather sparse in many respects, and it doesn't 
> say what the host firmware should or should not do during a resume.  So 
> the driver has to be very conservative and assume that any indication of a 
> change means that the entire controller must be reset.
> 
> > Suspend to disk still causes "virtual replugging"  and I think that controller is reset and will unplug/replug devices anyway
> > Resolving this problem is very difficult. Maybe it possible to check on unplugging event that this caused by suspend  if the same device is
> > replugged then don't remove/reinstall driver, but this is very difficult to implement properly,
> > Maybe just refuse to suspend if some valuable device is connected (sorry if it is done this way already)
> 
> Long ago I posted a patch that would take care of all this.  Not just for
> UHCI, but for any USB controller.  Maybe I should dig it out, update it,
> and submit it.
This sounds great, where is it ? .... :-)
This will improve linux suspend to ram/disk a lot.
> 
> > Also I want to note that I didn't yet checked any EHCI devices, because I don't have any (I am going to buy a usb stick soon)
> > But I feel that the above will be true for ehci too....
> 
> EHCI controllers tend to be better behaved than UHCI controllers, perhaps
> because the specification is much more careful to explain what must be
> done.  In many cases a computer can resume from suspend-to-RAM with all 
> the EHCI-connected devices still intact.
Big thanks, maybe usb stick I am going to buy will work with suspend to ram....
> 
> Alan Stern
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Hi,

	Thanks a lot for so quick reply,
	I want to note to myself that making a assumptions generally a bad idea,
	Until now I thought that linux always unplugs/re plugs usb devices on suspend/resume,
	that this is normal, but it looks that linux is better... :-)

	Best regards,
		Maxim Levitsky

Re: USB: on suspend to ram/disk all usb devices are replugged

[Pete Zaitcev]

On Tue, 27 Mar 2007 13:15:14 -0400 (EDT), Alan Stern <stern@rowland.harvard.edu> wrote:

> > Suspend to disk still causes "virtual replugging"  and I think that controller is reset and will unplug/replug devices anyway
> > Resolving this problem is very difficult. Maybe it possible to check on unplugging event that this caused by suspend  if the same device is
> > replugged then don't remove/reinstall driver, but this is very difficult to implement properly,
> > Maybe just refuse to suspend if some valuable device is connected (sorry if it is done this way already)
> 
> Long ago I posted a patch that would take care of all this.  Not just for
> UHCI, but for any USB controller.  Maybe I should dig it out, update it,
> and submit it.

Alan, BTW, look at this please:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233697

> From David Zeuthen

> If I suspend my box, then on the resume path I see all my USB devices being
> removed and then added back. This is a problem with storage devices connected
> via USB.
.....
> The kernel not send an "remove" event if it's going to send an "add" right
> after. Instead it should enumerate the bus on resume and only send the events
> that represents how to get from the previous device tree to the current one.

> From Pete Zaitcev

> What does happen if a user suspends, unplugs a USB key, modifies its contents,
> plugs it back, and resumes? In such a case, there would be no change between
> the state of USB bus between the before-suspend state and after-resume state.

> From David Zeuthen

> In that case the user would see data corruption - just as if he mounts a piece
> of removable media in a USB card reader; yanks out the card and modifies it
> elsewhere, and then puts it back in.

> I my opinion we can't really defend ourselves against such users... We can of
> course add checks in the file system drivers in the resume hooks to validate the
> super block and mount read-only if something change. 

The GNOME hath spoken?

-- Pete

Re: USB: on suspend to ram/disk all usb devices are replugged

[Maxim]

On Tuesday 27 March 2007 20:05:24 Pete Zaitcev wrote:
> On Tue, 27 Mar 2007 13:15:14 -0400 (EDT), Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > > Suspend to disk still causes "virtual replugging"  and I think that controller is reset and will unplug/replug devices anyway
> > > Resolving this problem is very difficult. Maybe it possible to check on unplugging event that this caused by suspend  if the same device is
> > > replugged then don't remove/reinstall driver, but this is very difficult to implement properly,
> > > Maybe just refuse to suspend if some valuable device is connected (sorry if it is done this way already)
> > 
> > Long ago I posted a patch that would take care of all this.  Not just for
> > UHCI, but for any USB controller.  Maybe I should dig it out, update it,
> > and submit it.
> 
> Alan, BTW, look at this please:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233697
> 
> > From David Zeuthen
> 
> > If I suspend my box, then on the resume path I see all my USB devices being
> > removed and then added back. This is a problem with storage devices connected
> > via USB.
> .....
> > The kernel not send an "remove" event if it's going to send an "add" right
> > after. Instead it should enumerate the bus on resume and only send the events
> > that represents how to get from the previous device tree to the current one.
> 
> > From Pete Zaitcev
> 
> > What does happen if a user suspends, unplugs a USB key, modifies its contents,
> > plugs it back, and resumes? In such a case, there would be no change between
> > the state of USB bus between the before-suspend state and after-resume state.
> 
> > From David Zeuthen
> 
> > In that case the user would see data corruption - just as if he mounts a piece
> > of removable media in a USB card reader; yanks out the card and modifies it
> > elsewhere, and then puts it back in.
> 
> > I my opinion we can't really defend ourselves against such users... We can of
> > course add checks in the file system drivers in the resume hooks to validate the
> > super block and mount read-only if something change. 
> 
> The GNOME hath spoken?
> 
> -- Pete
> 

Hi, 
	I also thought about that,
	
	I think that the best solution is still to hide connect/disconnect of usb devices from userspace (now it also causes corruption)
	But to refuse suspend with any usb mass storage device connected with mounted systems (and add a module param override
	 for users who know what they are doing)

	What do you think ?

	Regards,
		Maxim Levitsky

Re: USB: on suspend to ram/disk all usb devices are replugged

[Pavel Machek]

Hi!

> > > In that case the user would see data corruption - just as if he mounts a piece
> > > of removable media in a USB card reader; yanks out the card and modifies it
> > > elsewhere, and then puts it back in.
> > 
> > > I my opinion we can't really defend ourselves against such users... We can of
> > > course add checks in the file system drivers in the resume hooks to validate the
> > > super block and mount read-only if something change. 
> > 
> > The GNOME hath spoken?

> 	I also thought about that,
> 	
> 	I think that the best solution is still to hide connect/disconnect of usb devices from userspace (now it also causes corruption)
> 	But to refuse suspend with any usb mass storage device connected with mounted systems (and add a module param override
> 	 for users who know what they are doing)
> 
> 	What do you think ?

Agreed... and notice how easy is to do that in userspace :-))).

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: USB: on suspend to ram/disk all usb devices are replugged

[David Zeuthen]

On Sun, 2007-04-01 at 15:29 +0000, Pavel Machek wrote:
> Hi!
> 
> > > > In that case the user would see data corruption - just as if he mounts a piece
> > > > of removable media in a USB card reader; yanks out the card and modifies it
> > > > elsewhere, and then puts it back in.
> > > 
> > > > I my opinion we can't really defend ourselves against such users... We can of
> > > > course add checks in the file system drivers in the resume hooks to validate the
> > > > super block and mount read-only if something change. 
> > > 
> > > The GNOME hath spoken?
> 
> > 	I also thought about that,
> > 	
> > 	I think that the best solution is still to hide connect/disconnect of usb devices from userspace (now it also causes corruption)
> > 	But to refuse suspend with any usb mass storage device connected with mounted systems (and add a module param override
> > 	 for users who know what they are doing)
> > 
> > 	What do you think ?
> 
> Agreed... and notice how easy is to do that in userspace :-))).
> 

The problem with refusing to suspend with usb mass storage devices
mounted is just not going to work; the way we want desktop power
management to work is that the system automatically does s2ram or s2disk
when

 - the system is idle
 - the user closes the laptop lid
   (all this is of course configurable but these are the defaults
    in many distributions of Linux.)

and the kernel refusing to suspend in these cases may result in e.g. the
laptop melting because the lid is closed. For example, in
gnome-power-manager we play a loud "boohoo" sound if suspend fails when
closing the lid. It's all we can do really, the user have closed the lid
and if we didn't alert her _in some way_ the result would be a melted
laptop. You have to realize that people use their system in such a way.

Suspending when idle is really important too, since at some point there
will be legislation (akin to accessibility, e.g. the US's section 508)
that mandates that e.g. the US government will not buy systems that
don't conserve power by going to sleep when idle. That's an incentive at
least for "enterprise distributions" to fix this; more importantly, I
personally think that we have a moral obligation to do all that we can
to conserve power. Refusing to suspend means that many systems with USB
mass storage devices attached will consume e.g. 300W instead of 8W. I
don't know about you, but that sounds awfully wasteful to me.

And there's this: suggesting to just provide an option for people to
override this is not useful; any sane desktop distro will use that
override because users _expect_ that their laptop suspends when they
close the lid and they don't really or know care whether some drive is
connected via USB.

I hate to play this card, but you may want to look at other desktop
operating systems like Mac OS X and Windows - they don't give you USB
disconnects/reconnects on suspend and apps runs fine and can continue
accessing files on mounted USB devices upon resume.

I hope this clarifies the request. Thanks for considering.

      David

Re: USB: on suspend to ram/disk all usb devices are replugged

[Pavel Machek]

Hi!

> > > > The GNOME hath spoken?
> > 
> > > 	I also thought about that,
> > > 	
> > > 	I think that the best solution is still to hide connect/disconnect of usb devices from userspace (now it also causes corruption)
> > > 	But to refuse suspend with any usb mass storage device connected with mounted systems (and add a module param override
> > > 	 for users who know what they are doing)
> > > 
> > > 	What do you think ?
> > 
> > Agreed... and notice how easy is to do that in userspace :-))).
> 
> The problem with refusing to suspend with usb mass storage devices
> mounted is just not going to work; the way we want desktop power

Problem is that suspending _with_ removable mass storage devices
attached just will not work. User will unplug them, then complain
about corruption. Advanced user will unplug them, work with them
somewhere else, replug them, then loose filesystem.

Feel free to send patch to teach filesystems to handle this.

> management to work is that the system automatically does s2ram or s2disk
> when
> 
>  - the system is idle
>  - the user closes the laptop lid
>    (all this is of course configurable but these are the defaults
>     in many distributions of Linux.)
> 
> and the kernel refusing to suspend in these cases may result in e.g. the
> laptop melting because the lid is closed. For example, in

Check your facts. Laptops do not melt. I know, I put them into my bed,
covered with pillow, and let them complain (evo 560c). ACPI thermals
can handle that.

> gnome-power-manager we play a loud "boohoo" sound if suspend fails when
> closing the lid. It's all we can do really, the user have closed the lid
> and if we didn't alert her _in some way_ the result would be a melted
> laptop. You have to realize that people use their system in such a
> way.

You have to realize what is possible and what is not.

> Suspending when idle is really important too, since at some point there
> will be legislation (akin to accessibility, e.g. the US's section

Yep? Create the filesystem patch, then.

> And there's this: suggesting to just provide an option for people to
> override this is not useful; any sane desktop distro will use that
> override because users _expect_ that their laptop suspends when they
> close the lid and they don't really or know care whether some drive is
> connected via USB.

If you don't care or care about your data, feel free to (patch your
kernel to) suspend with removable disks mounted.

> I hate to play this card, but you may want to look at other desktop

You are indeed should know better than speaking like this on lkml.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: USB: on suspend to ram/disk all usb devices are replugged

[David Zeuthen]

On Sun, 2007-04-01 at 19:50 +0200, Pavel Machek wrote:
> Problem is that suspending _with_ removable mass storage devices
> attached just will not work. User will unplug them, then complain
> about corruption. Advanced user will unplug them, work with them
> somewhere else, replug them, then loose filesystem.
> 
> Feel free to send patch to teach filesystems to handle this.

I was suggesting in the Bugzilla that the file system should actually do
this. I don't have a patch for this, sorry. 

> Check your facts. Laptops do not melt. I know, I put them into my bed,
> covered with pillow, and let them complain (evo 560c). ACPI thermals
> can handle that.

Some laptops may severely overheat especially if the backlight is not
turned off (See: Apple hardware). Pretending that all hardware "just
works" or that all drivers "just work" is nice but not really useful in
the real life especially when we're talking about damaging hardware.

     David

Re: USB: on suspend to ram/disk all usb devices are replugged

[Pavel Machek]

Hi!

> > Problem is that suspending _with_ removable mass storage devices
> > attached just will not work. User will unplug them, then complain
> > about corruption. Advanced user will unplug them, work with them
> > somewhere else, replug them, then loose filesystem.
> > 
> > Feel free to send patch to teach filesystems to handle this.
> 
> I was suggesting in the Bugzilla that the file system should actually do
> this. I don't have a patch for this, sorry. 

Unfortunately it is a _lot_ of work, so noone has time for that :-(.

> > Check your facts. Laptops do not melt. I know, I put them into my bed,
> > covered with pillow, and let them complain (evo 560c). ACPI thermals
> > can handle that.
> 
> Some laptops may severely overheat especially if the backlight is not
> turned off (See: Apple hardware). Pretending that all hardware "just
> works" or that all drivers "just work" is nice but not really useful in
> the real life especially when we're talking about damaging hardware.

Apple should fix their hardware, then. And you should not run Linux
there, because their hardware is broken; they assume OS X.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: USB: on suspend to ram/disk all usb devices are replugged

[Alan Stern]

On Sun, 1 Apr 2007, Pavel Machek wrote:

> Hi!
> 
> > > > > The GNOME hath spoken?
> > > 
> > > > 	I also thought about that,
> > > > 	
> > > > 	I think that the best solution is still to hide connect/disconnect of usb devices from userspace (now it also causes corruption)
> > > > 	But to refuse suspend with any usb mass storage device connected with mounted systems (and add a module param override
> > > > 	 for users who know what they are doing)
> > > > 
> > > > 	What do you think ?
> > > 
> > > Agreed... and notice how easy is to do that in userspace :-))).
> > 
> > The problem with refusing to suspend with usb mass storage devices
> > mounted is just not going to work; the way we want desktop power
> 
> Problem is that suspending _with_ removable mass storage devices
> attached just will not work. User will unplug them, then complain
> about corruption. Advanced user will unplug them, work with them
> somewhere else, replug them, then loose filesystem.
> 
> Feel free to send patch to teach filesystems to handle this.

Actually what's needed is a Persistent Logical Volume Manager.  With it,
you could even mount a filesystem on a USB device, unplug the device, plug
it back into a different port, and still be able to use the filesystem.

But you're still likely to run into trouble if you unplug a storage
device, move it to another system and write on it, then plug it back into
the original system.  The PLVM would somehow have to recognize that the
data had been changed.  I don't know a foolproof way of doing that.

Alan Stern

Re: USB: on suspend to ram/disk all usb devices are replugged

[Pavel Machek]

Hi!

> > Problem is that suspending _with_ removable mass storage devices
> > attached just will not work. User will unplug them, then complain
> > about corruption. Advanced user will unplug them, work with them
> > somewhere else, replug them, then loose filesystem.
> > 
> > Feel free to send patch to teach filesystems to handle this.
> 
> Actually what's needed is a Persistent Logical Volume Manager.  With it,
> you could even mount a filesystem on a USB device, unplug the device, plug
> it back into a different port, and still be able to use the filesystem.
> 
> But you're still likely to run into trouble if you unplug a storage
> device, move it to another system and write on it, then plug it back into
> the original system.  The PLVM would somehow have to recognize that the
> data had been changed.  I don't know a foolproof way of doing that.

Such detection should be possible when done at filesystem level.

I.e. ext3 would notice that someone replayed the journal.

Or we could create ext5 where each r/w mount would update mount
time... actually we probably already have last mount time in ext3,
so...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: USB: on suspend to ram/disk all usb devices are replugged

[Rafael J. Wysocki]

Hi,

On Sunday, 1 April 2007 20:34, Pavel Machek wrote:
> Hi!
> 
> > > Problem is that suspending _with_ removable mass storage devices
> > > attached just will not work. User will unplug them, then complain
> > > about corruption. Advanced user will unplug them, work with them
> > > somewhere else, replug them, then loose filesystem.
> > > 
> > > Feel free to send patch to teach filesystems to handle this.
> > 
> > Actually what's needed is a Persistent Logical Volume Manager.  With it,
> > you could even mount a filesystem on a USB device, unplug the device, plug
> > it back into a different port, and still be able to use the filesystem.
> > 
> > But you're still likely to run into trouble if you unplug a storage
> > device, move it to another system and write on it, then plug it back into
> > the original system.  The PLVM would somehow have to recognize that the
> > data had been changed.  I don't know a foolproof way of doing that.
> 
> Such detection should be possible when done at filesystem level.
> 
> I.e. ext3 would notice that someone replayed the journal.
> 
> Or we could create ext5 where each r/w mount would update mount
> time... actually we probably already have last mount time in ext3,
> so...

I'm thinking we'll need to introduce something like freezing notifiers, ie.
the ability to register a notifier by an interested subsystem that will be
called right after user space processes have been frozen and right before
we start to thaw them (that may allow us to handle the microcode issue in
a clean way, for example).

Now if a filesystem registers a freezing notifier, it may be unmounted during
the suspend and remounted during the resume in more or less transparent
way.  I think an additional mount flag would be needed for filesystem that
should install such notifiers, like "removable".

Greetings,
Rafael

Re: USB: on suspend to ram/disk all usb devices are replugged

[Alan Stern]

On Sun, 1 Apr 2007, Rafael J. Wysocki wrote:

> Hi,
> 
> On Sunday, 1 April 2007 20:34, Pavel Machek wrote:
> > Hi!
> > 
> > > > Problem is that suspending _with_ removable mass storage devices
> > > > attached just will not work. User will unplug them, then complain
> > > > about corruption. Advanced user will unplug them, work with them
> > > > somewhere else, replug them, then loose filesystem.
> > > > 
> > > > Feel free to send patch to teach filesystems to handle this.
> > > 
> > > Actually what's needed is a Persistent Logical Volume Manager.  With it,
> > > you could even mount a filesystem on a USB device, unplug the device, plug
> > > it back into a different port, and still be able to use the filesystem.
> > > 
> > > But you're still likely to run into trouble if you unplug a storage
> > > device, move it to another system and write on it, then plug it back into
> > > the original system.  The PLVM would somehow have to recognize that the
> > > data had been changed.  I don't know a foolproof way of doing that.
> > 
> > Such detection should be possible when done at filesystem level.
> > 
> > I.e. ext3 would notice that someone replayed the journal.
> > 
> > Or we could create ext5 where each r/w mount would update mount
> > time... actually we probably already have last mount time in ext3,
> > so...
> 
> I'm thinking we'll need to introduce something like freezing notifiers, ie.
> the ability to register a notifier by an interested subsystem that will be
> called right after user space processes have been frozen and right before
> we start to thaw them (that may allow us to handle the microcode issue in
> a clean way, for example).
> 
> Now if a filesystem registers a freezing notifier, it may be unmounted during
> the suspend and remounted during the resume in more or less transparent
> way.  I think an additional mount flag would be needed for filesystem that
> should install such notifiers, like "removable".

"Unmounted" and "remounted" aren't quite the right words.  All you really
need to do is check (during the resume) that the superblock is still in
the same state as it was when the suspend occurred.  After all, if someone
else had mounted the dirty filesystem during the interim, they surely
would have altered the superblock.  Note that even a read-only mount of a
dirty ext3 filesystem will recover the journal; presumably that will alter
the superblock too.

I don't think a "removable" flag is needed.  There's no reason not to do 
this for every mounted filesystem.

(Also "removable" isn't the right word either, since hot-pluggable devices 
with non-removable media would need the same treatment.  In fact, while 
the system is hibernating someone could even remove an internal IDE drive 
and then put it back!)

One final nit:  It's possible for someone to alter the data sectors 
directly, without mounting the filesystem.  This is sufficiently perverse 
that we probably shouldn't worry about it.

Alan Stern

Re: USB: on suspend to ram/disk all usb devices are replugged

[Rafael J. Wysocki]

On Monday, 2 April 2007 04:54, Alan Stern wrote:
> On Sun, 1 Apr 2007, Rafael J. Wysocki wrote:
> 
> > Hi,
> > 
> > On Sunday, 1 April 2007 20:34, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > Problem is that suspending _with_ removable mass storage devices
> > > > > attached just will not work. User will unplug them, then complain
> > > > > about corruption. Advanced user will unplug them, work with them
> > > > > somewhere else, replug them, then loose filesystem.
> > > > > 
> > > > > Feel free to send patch to teach filesystems to handle this.
> > > > 
> > > > Actually what's needed is a Persistent Logical Volume Manager.  With it,
> > > > you could even mount a filesystem on a USB device, unplug the device, plug
> > > > it back into a different port, and still be able to use the filesystem.
> > > > 
> > > > But you're still likely to run into trouble if you unplug a storage
> > > > device, move it to another system and write on it, then plug it back into
> > > > the original system.  The PLVM would somehow have to recognize that the
> > > > data had been changed.  I don't know a foolproof way of doing that.
> > > 
> > > Such detection should be possible when done at filesystem level.
> > > 
> > > I.e. ext3 would notice that someone replayed the journal.
> > > 
> > > Or we could create ext5 where each r/w mount would update mount
> > > time... actually we probably already have last mount time in ext3,
> > > so...
> > 
> > I'm thinking we'll need to introduce something like freezing notifiers, ie.
> > the ability to register a notifier by an interested subsystem that will be
> > called right after user space processes have been frozen and right before
> > we start to thaw them (that may allow us to handle the microcode issue in
> > a clean way, for example).
> > 
> > Now if a filesystem registers a freezing notifier, it may be unmounted during
> > the suspend and remounted during the resume in more or less transparent
> > way.  I think an additional mount flag would be needed for filesystem that
> > should install such notifiers, like "removable".
> 
> "Unmounted" and "remounted" aren't quite the right words.  All you really
> need to do is check (during the resume) that the superblock is still in
> the same state as it was when the suspend occurred.

Yes, I was thinking of something more sophisticated, but this is what we need.

> After all, if someone 
> else had mounted the dirty filesystem during the interim, they surely
> would have altered the superblock.  Note that even a read-only mount of a
> dirty ext3 filesystem will recover the journal; presumably that will alter
> the superblock too.
> 
> I don't think a "removable" flag is needed.  There's no reason not to do 
> this for every mounted filesystem.

Well, I'm afraid about such filesystems as vfat ...

> (Also "removable" isn't the right word either, since hot-pluggable devices 
> with non-removable media would need the same treatment.  In fact, while 
> the system is hibernating someone could even remove an internal IDE drive 
> and then put it back!)

I meant the filesystems could be marked as "removable" rather than the
devices containing them, so that the users could tell us which filesystems
might need special handling.

> One final nit:  It's possible for someone to alter the data sectors 
> directly, without mounting the filesystem.  This is sufficiently perverse 
> that we probably shouldn't worry about it.

Agreed.

Greetings,
Rafael

Re: USB: on suspend to ram/disk all usb devices are replugged

[Chuck Ebbert]

Alan Stern wrote:
> On Sun, 1 Apr 2007, Pavel Machek wrote:
> 
>> Hi!
>>
>>>>>> The GNOME hath spoken?
>>>>> 	I also thought about that,
>>>>> 	
>>>>> 	I think that the best solution is still to hide connect/disconnect of usb devices from userspace (now it also causes corruption)
>>>>> 	But to refuse suspend with any usb mass storage device connected with mounted systems (and add a module param override
>>>>> 	 for users who know what they are doing)
>>>>>
>>>>> 	What do you think ?
>>>> Agreed... and notice how easy is to do that in userspace :-))).
>>> The problem with refusing to suspend with usb mass storage devices
>>> mounted is just not going to work; the way we want desktop power
>> Problem is that suspending _with_ removable mass storage devices
>> attached just will not work. User will unplug them, then complain
>> about corruption. Advanced user will unplug them, work with them
>> somewhere else, replug them, then loose filesystem.
>>
>> Feel free to send patch to teach filesystems to handle this.
> 
> Actually what's needed is a Persistent Logical Volume Manager.  With it,
> you could even mount a filesystem on a USB device, unplug the device, plug
> it back into a different port, and still be able to use the filesystem.
> 
> But you're still likely to run into trouble if you unplug a storage
> device, move it to another system and write on it, then plug it back into
> the original system.  The PLVM would somehow have to recognize that the
> data had been changed.  I don't know a foolproof way of doing that.
> 

Mark the filesystem as in-use with a one-time UUID in the superblock at
mount time. If one moved the drive to another system it would require
an fsck to clear the UUID before the other system could use it; then
the original machine would refuse to use the drive when the UUID didn't
match on resume.

Re: USB: on suspend to ram/disk all usb devices are replugged

[Pavel Machek]

Hi!

> > But you're still likely to run into trouble if you unplug a storage
> > device, move it to another system and write on it, then plug it back into
> > the original system.  The PLVM would somehow have to recognize that the
> > data had been changed.  I don't know a foolproof way of doing that.
> > 
> 
> Mark the filesystem as in-use with a one-time UUID in the superblock at
> mount time. If one moved the drive to another system it would require
> an fsck to clear the UUID before the other system could use it; then
> the original machine would refuse to use the drive when the UUID didn't
> match on resume.

You still need fs-specific code, I'm afraid... plus userland tool
to reset signatures back.

Patches welcome. 
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: USB: on suspend to ram/disk all usb devices are replugged

[Nigel Cunningham]

Hi.

On Mon, 2007-04-02 at 21:36 +0200, Pavel Machek wrote:
> Hi!
> 
> > > But you're still likely to run into trouble if you unplug a storage
> > > device, move it to another system and write on it, then plug it back into
> > > the original system.  The PLVM would somehow have to recognize that the
> > > data had been changed.  I don't know a foolproof way of doing that.
> > > 
> > 
> > Mark the filesystem as in-use with a one-time UUID in the superblock at
> > mount time. If one moved the drive to another system it would require
> > an fsck to clear the UUID before the other system could use it; then
> > the original machine would refuse to use the drive when the UUID didn't
> > match on resume.
> 
> You still need fs-specific code, I'm afraid... plus userland tool
> to reset signatures back.

You don't need userland to reset the signatures. More kernel code, sure.
But it doesn't _need_ to be userland.

Regards,

Nigel

Re: USB: on suspend to ram/disk all usb devices are replugged

[Mark Lord]

Pavel Machek wrote:
> ..
> Problem is that suspending _with_ removable mass storage devices
> attached just will not work. User will unplug them, then complain
> about corruption. Advanced user will unplug them, work with them
> somewhere else, replug them, then loose filesystem.
> 
> Feel free to send patch to teach filesystems to handle this.

People have already fixed this:  sync() before suspend,
and use a journalling filesystem.  Problem solved.

And when the rootfs is on an external drive, this is the *only* option.

So let's make it work (again, like it used to work!).

Re: USB: on suspend to ram/disk all usb devices are replugged

[Pavel Machek]

Hi!

> >Problem is that suspending _with_ removable mass 
> >storage devices
> >attached just will not work. User will unplug them, 
> >then complain
> >about corruption. Advanced user will unplug them, work 
> >with them
> >somewhere else, replug them, then loose filesystem.
> >
> >Feel free to send patch to teach filesystems to handle 
> >this.
> 
> People have already fixed this:  sync() before suspend,
> and use a journalling filesystem.  Problem solved.

Does not solve the 'user removed it and mounted it somewhere else in
the meantime' problem.

Alan proposed one possible solution....
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: USB: on suspend to ram/disk all usb devices are replugged

[Mark Lord]

Maxim Levitsky wrote:
> Hi,
> 	I noticed that after suspend/resume cycle all my usb devices are unplugged/replugged by uhci driver.
> While it is not that big problem to me, that can be a real problem if a device is a flash card with mounted 
> file-system, because disappeared device will cause file-system corruption.

Mmm.. this sounds really bad -- I wonder what happens if the rootfs is on USB ?
With older kernels, things just "worked" this way.  Has it now been broken ??

-ml

Re: USB: on suspend to ram/disk all usb devices are replugged

[Alan Stern]

On Thu, 29 Mar 2007, Mark Lord wrote:

> Maxim Levitsky wrote:
> > Hi,
> > 	I noticed that after suspend/resume cycle all my usb devices are unplugged/replugged by uhci driver.
> > While it is not that big problem to me, that can be a real problem if a device is a flash card with mounted 
> > file-system, because disappeared device will cause file-system corruption.
> 
> Mmm.. this sounds really bad -- I wonder what happens if the rootfs is on USB ?

The system crashes as soon as it resumes.  As you might expect.

> With older kernels, things just "worked" this way.  Has it now been broken ??

No; it has never worked.  Your memory of how older kernels behaved is 
wrong.

Alan Stern

P.S.: Help is on the way.  I will soon submit a patch to help improve the 
situation.

Re: USB: on suspend to ram/disk all usb devices are replugged

[Mark Lord]

Alan Stern wrote:
> On Thu, 29 Mar 2007, Mark Lord wrote:
>
>> Mmm.. this sounds really bad -- I wonder what happens if the rootfs is on USB ?
> 
> The system crashes as soon as it resumes.  As you might expect.
> 
>> With older kernels, things just "worked" this way.  Has it now been broken ??
> 
> No; it has never worked.  Your memory of how older kernels behaved is wrong.

Ah. Perhaps my Kubuntu system was using a FreeBSD kernel under the hood back then.
It really did work for me, back about 2 years ago when last attempted.
But then suspend/resume (RAM) has always worked here on every notebook
I've ever used -- apparently not the norm for others.  I just expect more.

> P.S.: Help is on the way.  I will soon submit a patch to help improve the situation.

That would be very good to see.

-ml