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 ...
[ message continues ]

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


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 

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,

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

-

[ message continues ]

Alan, BTW, look at this please:


The GNOME hath spoken?

-- Pete
-

[ message continues ]

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
-

[ message continues ]

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
-

[ message continues ]

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 ...
[ message continues ]

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.


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



If you don't care or care about your data, feel free to (patch your

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
-

[ message continues ]

I was suggesting in the Bugzilla that the file system should actually do

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


-

[ message continues ]

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
-

[ message continues ]

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

-

[ message continues ]

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
-

[ message continues ]

Hi,


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
-

[ message continues ]

"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

-

[ message continues ]

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

Agreed.

Greetings,
Rafael
-

[ message continues ]

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.

-

[ message continues ]

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
-

[ message continues ]

Hi.


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

Regards,

Nigel

-

[ message continues ]

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!).
-

[ message continues ]

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
-

[ message continues ]

This sounds great, where is it ? .... :-)

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
-

[ message continues ]

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
-

[ message continues ]

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.

-

[ message continues ]

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

That would be very good to see.

-ml
-

[ message continues ]