https://bugzilla.kernel.org/show_bug.cgi?id=220491 --- Comment #12 from Alan Stern (stern@xxxxxxxxxxxxxxxxxxx) --- Okay, this is different from before. Here's a comparison of the relevant parts (referring only to the messages for the card reader). The difference first appears when the device is reset following the resume and the computer reads the upstream USB port status. From the trace you originally attached (where the reset worked but the device failed later because of LPM): ffff9bbf9f9de0c0 215792020 S Ci:3:001:0 s a3 00 0000 0004 0004 4 < ffff9bbf9f9de0c0 215792047 C Ci:3:001:0 0 4 = 03021000 That 03021000 is a normal response; it means the port is powered, connected, and enabled, and the reset has completed. >From the trace with LPM disabled but where the resume failed: ffff8d32e6d06780 1883092024 S Ci:3:001:0 s a3 00 0000 0004 0004 4 < ffff8d32e6d06780 1883092046 C Ci:3:001:0 0 4 = d0024100 ffff8d32e6d06780 1883156157 S Ci:3:001:0 s a3 00 0000 0004 0004 4 < ffff8d32e6d06780 1883156182 C Ci:3:001:0 0 4 = 03025100 The Get-Port-Status request was issued twice. The first response indicates a vendor-specific link status (I guess it was some sort of intermediate state) and the second response shows the final result of the reset. 03025100 is not normal; it means that the port is powered, connected, and enabled (as before), but in addition to the completed reset there was a connect status change and a link-state change -- not surprising given the first response. This indicates the card reader disconnected and reconnected while the reset was taking place -- a rather peculiar thing for it to do. But I'm puzzled; at this point the kernel should have tried to reset the device again. Instead it continued on. We can see what happens next. The kernel tries to get the card reader's device descriptor. In the first trace this works, even though there's a useless intervening Set-Isochronous-Delay (in the third and fourth lines): ffff9bbf9f9de0c0 215864163 S Ci:3:003:0 s 80 06 0100 0000 0008 8 < ffff9bbf9f9de0c0 215864376 C Ci:3:003:0 0 8 =わ 12010003 00000009 ffff9bbf9f9de0c0 215864472 S Co:3:003:0 s 00 31 0028 0000 0000 0 ffff9bbf9f9de0c0 215864766 C Co:3:003:0 0 0 ffff9bbf9f9de0c0 215864862 S Ci:3:003:0 s 80 06 0100 0000 0012 18 < ffff9bbf9f9de0c0 215865180 C Ci:3:003:0 0 18 =わ 12010003 00000009 e3054707 19080304 0501 In the other trace, the Get-Device-Descriptor request fails completely, many times: ffff8d32e6d06180 1883228171 S Ci:3:005:0 s 80 06 0100 0000 0008 8 < ffff8d32e6d06180 1883228194 E Ci:3:005:0 -19 0 ffff8d32e6d06180 1883228195 S Ci:3:005:0 s 80 06 0100 0000 0008 8 < ffff8d32e6d06180 1883228209 E Ci:3:005:0 -19 0 ffff8d32e6d06180 1883228210 S Ci:3:005:0 s 80 06 0100 0000 0008 8 < ffff8d32e6d06180 1883228215 E Ci:3:005:0 -19 0 ffff8d32e6d06180 1883348155 S Ci:3:005:0 s 80 06 0100 0000 0008 8 < ffff8d32e6d06180 1883348174 E Ci:3:005:0 -19 0 ffff8d32e6d06180 1883348176 S Ci:3:005:0 s 80 06 0100 0000 0008 8 < ffff8d32e6d06180 1883348180 E Ci:3:005:0 -19 0 ffff8d32e6d06180 1883348181 S Ci:3:005:0 s 80 06 0100 0000 0008 8 < ffff8d32e6d06180 1883348185 E Ci:3:005:0 -19 0 The -19 error codes mean the device is considered to be disconnected, probably as a result of the connect- and link-state changes. At this point the kernel gives up; it had tried to recover the original device and the recovery failed. In the third trace (where the device continued to work after the resume), there was no connect-state or link-state change reported. The reset was okay and everything proceeded normally. I don't know that there's much we can do about this sort of thing -- that is, transient disconnects during reset-resume recovery. This was something that clearly happened _after_ the card reader had been resumed; it can't be chalked up to power loss during the suspend. To the kernel, it looked like the card reader really had been disconnected from the USB bus during the reset and a new device connected in its place. The xhci-hcd debugging information can't help; all it might say is that there was a disconnect and a connect, which we already know. To find out the cause it would be necessary to know what's going on inside the card reader's firmware. You can check this interpretation of events by turning on usbcore dynamic debugging and seeing what the kernel log says when this happens again. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.