Re: USB resume guarantees

On Sunday 11 November 2007, Tilman Schmidt wrote:
> While trying to add suspend/resume support to the USB drivers I
> maintain, I came across the following unexpected sequence of
> events with kernel 2.6.24-rc2:
> 
> - I request suspend to disk by doing
>   echo shutdown > /sys/power/disk ; echo disk > /sys/power/state
> 
> - My driver's suspend method is called, which uses
>   tasklet_disable() to prevent a tasklet from resubmitting URBs.

It should also make sure no URBs are pending.


> - The system powers down as expected.
> 
> - I power it up again.
> 
> - The USB subsystem (compiled with CONFIG_USB_DEBUG) syslogs
>   "root hub lost power or was reset" for all the USB busses.

Right.  A true suspend -- "echo standby > /sys/power/state"
or "echo mem > /sys/power/state" -- generally won't power
down peripherals.

Hibernation normally does power everything off, and that's why
it's handled differently.  Especially in the case of USB,
which was designed to report such power loss.


> - My driver's disconnect method is called. *Not* the resume
>   method, *not* the reset_resume method, *just* the disconnect
>   method.

Which is perfectly fine.  If someone disconnected the device
while the system was suspended, that's what would happen.

Consider the example of a disk drive with a mounted filesystem.
Suspend, disconnect the drive, mount it on a different system,
update lots of stuff, unmount it, reconnect it, power the system
back up from hibernation.  If Linux did NOT treat that disk as
if it were disconnected, and continued using the state it had
previously cached, you'd end up with lots of needlessly garbaged
data on that disk...


> - My driver's probe method is called.
> 
> - Driver operation is blocked because the tasklet is still
>   disabled. There are tasklet_enable() calls in my resume and
>   reset_resume methods, but those were never called.

That's a bug in your disconnect() method.  Why would a
tasklet associated with a disconnected device affect
any other device?


> - When I unplug the device to clear up the condition, khubd
>   and ksoftirqd start hogging my CPU.

That's unfriendly.  You should find out why.  My first
guess would be that your disconnect() method misbehaved
badly ...


> From reading Documentation/usb/power-management.txt I gathered
> the impression that suspend and resume/reset_resume calls would
> be paired,

In the normal case, yes.  (Though I don't think I've doe
more than skim that text ...)

Power-off cases are not normal, and they've always been
handled by the suspend -> disconnect transition (followed
by a re-enumeration).  There's some experimental stuff
to treat those hibernation cases differently, but I highly
discourage folk from enabling that Kconfig option.

- Dave


> iow I could rely on either resume or reset_resume 
> being called once for every call of suspend, but obviously that
> ain't so. So what are the possible sequences of events my driver
> must be prepared to cope with?
> 
> Thanks
> Tilman
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel