On Fri, Jan 18, 2013 at 02:09:26PM -0500, Alan Stern wrote:
> On Fri, 18 Jan 2013, Sarah Sharp wrote:
>
> > Hi Alan,
> >
> > What's the current state of USB mass storage suspend? I know there was
> > some purposed changes to the SCSI or block layer that would have
> > effected suspend, and I wondered if those made it in.
>
> The block-layer autosuspend patches are in pretty good shape. I
> haven't heard any objections to them recently from James Bottomley or
> Jens Axboe, so maybe they'll be accepted soon.
Can you remind me how those patches will change the current auto-suspend
behavior?
> Don't forget that autosuspend for mass storage is available right now,
> in 3.7 and earlier kernels. It affects only disks whose device file
> isn't open (hence no mounted filesystems on the disk), and it has to be
> enabled by userspace (write "auto" to power/control for the SCSI disk
> device and its ancestors).
Ok, just to verify, say I have this tree:
sarah@xanatos:~$ lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 2, If 0, Class=stor., Driver=usb-storage, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 12M
|__ Port 2: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M
|__ Port 2: Dev 3, If 1, Class=HID, Driver=usbhid, 1.5M
|__ Port 3: Dev 4, If 0, Class=HID, Driver=usbhid, 1.5M
|__ Port 3: Dev 4, If 1, Class=HID, Driver=usbhid, 1.5M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
|__ Port 6: Dev 3, If 0, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M
|__ Port 6: Dev 3, If 1, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M
If I want the usb-storage device to suspend, I would have to run:
root@xanatos:/sys/bus/usb/devices/4-2/power# echo auto > control
root@xanatos:/sys/bus/usb/devices/4-2/power# echo 100 > autosuspend_delay_ms
Auto-suspend is already enabled for the roothub. I unmounted the
filesystem on the SD card, and then waited for the port to go into U3.
That never happened, although I could see the port transition into other
link power states like U2.
I'm not sure why the device isn't going into U3. I have
CONFIG_USB_SUSPEND turned on for this kernel.
> > I'm specifically looking for when we can expect a USB storage device to
> > go into auto-suspend. If userspace enables auto-suspend and sets the
> > autosuspend_delay_ms to zero, could we see auto-suspend between SCSI
> > commands? Or will the device remain in U0 until the storage device is
> > unmounted?
>
> The autosuspend delay at the USB level probably should be set to 0;
> then the autosuspend delay at the SCSI disk level will control the
> actual power changes.
Is there a way to get at the auto-suspend delay at the SCSI disk level
through sysfs? What's the default timeout?
> I'm not sure if everything will work correctly with the delay set to 0.
> In theory you would indeed see autosuspend kicking in between SCSI
> commands. But the implementation might not work correctly under those
> conditions -- I didn't care about that case because it shouldn't be
> used.
>
> On the other hand, it should work as expected once the autosuspend
> delay is set to a not-unreasonable value, say 100 ms or anything
> larger. The drive should indeed go into suspend whenever the interval
> between SCSI commands is longer than the autosuspend delay (within a
> factor of 2).
>
> Note that drives with removable media are polled automatically by the
> kernel at intervals of 2 seconds by default. If the autosuspend delay
> is longer than that, it will never have a chance to take effect.
Isn't there a sysfs file to control the polling rate for removable
media? I don't remember where is it though. (I seem to ask about mass
storage suspend approximately once a year, and the state gets swapped
out in that time. :)
Sarah
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
