On Tue, 12 Feb 2019, Mathias Nyman wrote: > On 11.02.2019 18:38, Eric Blau wrote: > > On Mon, Feb 11, 2019 at 10:25 AM Mathias Nyman > > <mathias.nyman@xxxxxxxxxxxxxxx> wrote: > >> > >> Can I ask you to take yet another set of logs, same as before, xhci traces, and > >> usbcore and xhci dynamic debug, but preferably everything from boot up to and including > >> a failed system suspend event. > > > > In the course of trying to capture the logs you asked for, the first > > time I was actually not able to reproduce the problem even after > > suspending 5-6 times. I never saw a port stuck in polling and suspends > > never failed. After I cold booted my laptop and tried again, the > > problem occurred again. > > > > 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? Alan Stern
