On Tue, Feb 12, 2019 at 1:06 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 12 Feb 2019, Mathias Nyman wrote: > > > > > This logs shows a USB3 Apple card reader successfully suspending to U3 state > > once, but fails to resume back to U0. It is logically disconnected as a result of > > failing to resume, and is left stuck in a polling link state. > > > > This is the only USB3 device connected. The polling link state does not yet show the device > > as connected or enabled, so hub attempts to autosuspend. > > There is however a final check before autosuspending the hub which prevents suspend > > due to the port in polling state. This autosuspend attempt continues in a loop. > > I don't know what the right answer is here. But we shouldn't allow > faulty peripherals to prevent the system from going into suspend. > > Should we give up after some fixed number of warm resets, say 5? Thanks for looking into this, Mathias. Now that you point this out, on older kernels where suspend and resume works, I noticed the following log messages emitted when resuming from suspend: Feb 06 18:58:05 eric-macbookpro kernel: usb usb2-port3: Cannot enable. Maybe the USB cable is bad? Feb 06 18:58:05 eric-macbookpro kernel: usb 2-3: USB disconnect, device number 2 Feb 06 18:58:09 eric-macbookpro kernel: usb usb2-port3: Cannot enable. Maybe the USB cable is bad? Feb 06 18:58:13 eric-macbookpro kernel: usb usb2-port3: Cannot enable. Maybe the USB cable is bad? Feb 06 18:58:17 eric-macbookpro kernel: usb usb2-port3: Cannot enable. Maybe the USB cable is bad? Feb 06 18:58:21 eric-macbookpro kernel: usb usb2-port3: Cannot enable. Maybe the USB cable is bad? Feb 06 18:58:21 eric-macbookpro kernel: usb usb2-port3: unable to enumerate USB device It seems like the faulty device fails to be enabled but then the kernel gives up on it after a couple tries. It looks like it used to do what Alan suggests, trying 5 times and then giving up. Regards, Eric
