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