[Bug 220491] usb_storage connected SD card disconnects/reconnects on resume from suspend

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=220491

--- Comment #12 from Alan Stern (stern@rowland.harvard.edu) ---
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.