On 15.03.2017 22:48, Nathan Shearer wrote:
Does earlier kernels work better? 4.10 has a change in USB 3 port
disabling
which is also called when usb core fails to address a device.
37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3
devices
Older kernels would re-enable usb3 ports immediately after port disable.
I can try some older kernels if it will help. Which versions should I
compile and try?
4.9 without any additions
Does dock work in other ports after power cycle?
No. I'm using usb ports directly on the motherboard, and once the
port/dock is disabled, it continues to not work even if I transfer the
dock to another port. My USB keyboard and mouse do continue to work though.
Odd, sounds like the Dock gets into some really weird state.
does disabled port react to other USB devices?
Yes, connecting a 2nd USB keyboard+mouse combo device to the disabled
port does work. Connecting the usb dock back to that port again and the
dock is still disabled. Connecting a small USB drive to the same port
and the small usb drive does work. It seems the computer/kernel is
remembering that the dock is a disabled device somehow.
Sounds like the device is really in a odd state.
Here is /var/log/messages for Vanilla Sources 4.10.3 with xhci debugging
enabled
(cleaned it up a bit)
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Successful setup address command
Mar 15 13:48:50 varws03 kernel: usb 4-4: new SuperSpeed USB device number 2 using xhci_hcd
Mar 15 13:48:50 varws03 kernel: usb 4-4: New USB device found, idVendor=0480, idProduct=a006
Mar 15 13:48:50 varws03 kernel: usb 4-4: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Mar 15 13:48:50 varws03 kernel: usb 4-4: Product: ASM1351
Mar 15 13:48:50 varws03 kernel: usb 4-4: Manufacturer: Asmedia
Mar 15 13:48:50 varws03 kernel: usb 4-4: SerialNumber: 123456789116
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Successful Endpoint Configure command
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Set up evaluate context for LPM MEL change.
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Successful evaluate context command
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Set up evaluate context for LPM MEL change.
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Successful evaluate context command
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Set up evaluate context for LPM MEL change.
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Successful evaluate context command
Way too many Maximum exit latency (MEL) commands, probably due to unnecessary
U1 and U2 enable/disable requests.
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Adding 2 ep ctxs, 13 now active.
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Successful Endpoint Configure command
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Set up evaluate context for LPM MEL change.
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Successful evaluate context command
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Driver wants 257 stream IDs (including stream 0).
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Ep 0x83 only supports 32 stream IDs.
driver asking for 257 streams, ep supports 32.
Oliver, does this look normal for UAS?
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Need 64 stream ctx entries for 33 stream IDs.
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Allocating 33 streams and 64 stream context array entries.
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Setting stream 1 ring ptr to 0x400c57003
...
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Setting stream 32 ring ptr to 0x400c9f003
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Allocating 33 streams and 64 stream context array entries.
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Setting stream 1 ring ptr to 0x400ca2003
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Setting stream 32 ring ptr to 0x400ce2003
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Allocating 33 streams and 64 stream context array entries.
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Setting stream 32 ring ptr to 0x400d25003
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Setting number of stream ctx array entries to 64
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Setting number of stream ctx array entries to 64
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Setting number of stream ctx array entries to 64
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: Successful Endpoint Configure command
Mar 15 13:48:50 varws03 kernel: usbcore: registered new interface driver uas
Mar 15 13:48:50 varws03 kernel: xhci_hcd 0000:00:14.0: ep 0x83 - asked
Mar 15 13:48:50 varws03 kernel: sd 6:0:0:0: [sdb] Spinning up disk...
Mar 15 13:49:29 varws03 kernel: sd 6:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
Something went wrong, I guess UAS driver starts to cancel URBs
Mar 15 13:49:29 varws03 kernel: sd 6:0:0:0: tag#0 CDB: Read capacity(16) 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00
Mar 15 13:49:29 varws03 kernel: xhci_hcd 0000:00:14.0: Cancel URB
ffff88045ba53480, dev 4, ep 0x81, starting at offset 0x400ca2060
Mar 15 13:49:29 varws03 kernel: xhci_hcd 0000:00:14.0: Cancel URB
ffff88045ba53c00, dev 4, ep 0x83, starting at offset 0x400c571c0
Mar 15 13:49:29 varws03 kernel: xhci_hcd 0000:00:14.0: // Ding dong!
Mar 15 13:49:29 varws03 kernel: xhci_hcd 0000:00:14.0: Adding 0 ep ctxs, 13 now active.
Mar 15 13:49:29 varws03 kernel: xhci_hcd 0000:00:14.0: Successful Endpoint Configure command
Mar 15 13:49:34 varws03 kernel: xhci_hcd 0000:00:14.0: Cancel URB
ffff88045ca64000, dev 4, ep 0x0, starting at offset 0x4109113a0
Here we cancel control endpoint URB, probably a U1 or U2 enable/disable request,
Mar 15 13:49:34 varws03 kernel: xhci_hcd 0000:00:14.0: // Ding dong!
Mar 15 13:49:34 varws03 kernel: xhci_hcd 0000:00:14.0: WARN: unexpected TRB Type 4
And we stop at the last status stage (Type 4) of that request
This is completely ok, That WARN: message is wrong, I'll fix that, but it
probably doesn't matter for the functionality anyway.
Mar 15 13:49:34 varws03 kernel: usb 4-4: Disable of device-initiated U1 failed.
Mar 15 13:49:39 varws03 kernel: xhci_hcd 0000:00:14.0: Cancel URB
ffff88043a9cc180, dev 4, ep 0x0, starting at offset 0x4109113c0
Mar 15 13:49:39 varws03 kernel: xhci_hcd 0000:00:14.0: WARN: unexpected TRB Type 4
Mar 15 13:49:39 varws03 kernel: usb 4-4: Disable of device-initiated U2 failed.
Mar 15 13:49:39 varws03 kernel: xhci_hcd 0000:00:14.0: Set up evaluate context for LPM MEL change.
Mar 15 13:49:39 varws03 kernel: xhci_hcd 0000:00:14.0: Successful evaluate context command
Mar 15 13:49:39 varws03 kernel: xhci_hcd 0000:00:14.0: Resetting
device with slot ID 3
Mar 15 13:49:39 varws03 kernel: xhci_hcd 0000:00:14.0: Completed reset device command.
Mar 15 13:49:39 varws03 kernel: xhci_hcd 0000:00:14.0: Successfulreset device command.
Mar 15 13:49:39 varws03 kernel: xhci_hcd 0000:00:14.0: Dropped 4 ep ctxs, flags = 0xcc, 9 now active.
Mar 15 13:49:45 varws03 kernel: xhci_hcd 0000:00:14.0: Command timeout
Mar 15 13:49:45 varws03 kernel: xhci_hcd 0000:00:14.0: Abort command ring
Mar 15 13:49:45 varws03 kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
Mar 15 13:49:50 varws03 kernel: xhci_hcd 0000:00:14.0: Command timeout
Mar 15 13:49:50 varws03 kernel: xhci_hcd 0000:00:14.0: Abort command ring
Mar 15 13:49:50 varws03 kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
Mar 15 13:49:51 varws03 kernel: usb 4-4: device not accepting address 2, error -62
.. and so on, we try to enumerate the device but it doesn't respond to set
address, and times out. First impression is that host side does what it can
correctly, but device (dock) just doesn't respond anymore.
besides using 4.9 kernel you could try disabling power management and using mass
storage instead of UAS.
Can you try out some testpatches if I write them?
I need to fix that excessive U1/U2 enablig/disabling,
and the "WARN: unexptected TRB Type 4" anyway.
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
