Re: "Set SEL for device-initiated U1 failed." errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux