On Thu, 29 Aug 2013, Sarah Sharp wrote:
> On Thu, Aug 29, 2013 at 10:06:16AM -0700, Greg Kroah-Hartman wrote:
> > Hi Sarah,
> >
> > I'm getting the following warnings from the 3.10.9 kernel all the time
> > when I unplug a USB 3 storage device from my laptop:
> > [203282.987687] usb 4-1: USB disconnect, device number 21
> > [203282.992904] usb 4-1: Set SEL for device-initiated U1 failed.
> > [203282.992909] usb 4-1: Set SEL for device-initiated U2 failed.
> >
> > What can a "normal" user do with these "failed" messages? If nothing,
> > shouldn't we just turn them into debug messages instead?
>
> Yes, those messages should probably be toned down to debug level instead
> of warning level. If a device doesn't respond to the Set SEL request
> when USB 3.0 LPM is enabled, the user has a buggy device. Of course, I
> doubt anyone is going to return a drive based on those messages.
>
> That error message happens because the USB core is attempting to disable
> LPM for a disconnected device. The control transfer to set SEL fails,
> resulting in those messages. The xHCI driver still needs to disable the
> U1 and U2 timeouts for the port, so the core still needs to call into
> usb_set_lpm_timeout. However, we could skip the control transfer to the
> device.
>
> The problem is that the USB core doesn't mark the device as DISCONNECTED
> until after it attempts to disable LPM.
Are you certain? Look at the order of the lines in the log above.
> The device is still marked as
> being in the configured state, because we don't return early in this
> function:
>
> static int usb_set_device_initiated_lpm(struct usb_device *udev,
> enum usb3_link_state state, bool enable)
> {
...
> }
>
> So I don't know how the LPM code can know the device is disconnected, and thus
> it should skip the control transfer. Do we get an -ENODEV in that case?
That doesn't sound right at all. This function is called from
usb_disable_link_state, which is called from usb_disable_lpm, which is
called from usb_unlocked_disable_lpm, which is called from
usb_disable_device, which is called from usb_disconnect.
The first thing usb_disconnect does is change udev->state to
STATE_NOTATTACHED. Therefore you can test for that in
usb_set_device_initiated_lpm, and avoid trying to send messages that
will never be received. Or if you prefer, avoid writing anything to
the log when the transfer fails with -ENODEV.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
