On Fri, Aug 30, 2013 at 02:58:25AM +0800, Alan Stern wrote:
> 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
disable LPM or in case of enable LPM? Is n't this warning message
coming from usb_enable_lpm -> usb_enable_link_state
3600 ret = usb_req_set_sel(udev, state);
3601 if (ret < 0) {
3602 dev_warn(&udev->dev, "Set SEL for
device-initiated %s failed.\n",
3603 usb3_lpm_names[state]);
3604 return;
3605 }
> > 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
In fact it has been tested in usb_set_device_initiated_lpm.
3490 if (udev->state != USB_STATE_CONFIGURED) {
3491 dev_dbg(&udev->dev, "%s: Can't %s %s state "
3492 "for unconfigured device.\n",
3493 __func__, enable ? "enable" :
"disable",
3494 usb3_lpm_names[state]);
3495 return 0;
3496 }
So, may be problem is somewhere else which need to be tracked down.
Regards
Pratyush
> 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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
