[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 #34 from Paul Ausbeck (paula@alumni.cse.ucsc.edu) ---
Alan: It may be that the usbmon trace associated with comment #9 is not what I
thought it was. Since I can't readily interpret these traces I can't verify
that they contain what I think they contain. I may have made a mistake.

When I say that a device disconnects/reconnects I get this information from the
dmesg log. I did my best to match the usbmon trace to a proper dmesg log but I
may have made a mistake. I want to emphasize that every time the device
disconnects/reconnects as far as the dmesg log is concerned, the USB filesystem
is unmounted. Every time that the device merely resets and does not
disconnect/reconnect the USB filesystem remains mounted.

Here is a log snippet where the device, 3-4, disconnects/reconnects:

[22784.760311] usb 3-4: USB disconnect, device number 3
[22784.761239] pci_bus 0000:01: Allocating resources
[22784.761855] pci_bus 0000:01: Allocating resources
[22784.762047] done.
[22784.762056] random: crng reseeded on system resumption
[22784.876977] PM: suspend exit
[22784.878740] usb 2-4: new full-speed USB device number 15 using xhci_hcd
[22785.031677] usb 2-4: New USB device found, idVendor=0cf3, idProduct=e300,
bcdDevice= 0.01
[22785.031687] usb 2-4: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[22785.036360] usb 2-4: USB disconnect, device number 15
[22785.214926] usb 3-4: new SuperSpeed USB device number 4 using xhci_hcd

Here is what a reset with no disconnect/reconnect looks like:

[   58.003736] usb 3-4: reset SuperSpeed USB device number 2 using xhci_hcd

If the device is always disconnecting/reconnecting at the usbmon level, this is
not always being propagated up to the usbcore level. To the extent that is
true, the usb_persist mechanism is already working at least part of the time.
If usb_persist is already working part of the time that should make it easier
to get it to work all the time.

Just to verify that I did not make a mistake on comment #9, I'll attach another
usbmon trace where there is no disconnect/reconnect at the usbcore level. The
trace that I'm attaching has Bi/Bo:3:002 in every line. I interpret this as
meaning that the host is only talking to the USB storage device. When a
disconnect/reconnect occurs I also see usbmon lines that contain Bi/Bo:3:001,
which I interpret as talking to the associated hub, and Bi/Bo:3:003 which I
interpret as talking to the reincarnated device through a new device ID.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.