On Tue, 9 Apr 2013, infernix wrote:
Hi,
For some time now (at least since 3.0) I have been having issues with an
USB3 to Sata enclosure and xHCI. The device (174c:55aa ASMedia
Technology Inc) works perfectly fine on USB2 ports in Linux, as well as
on the NEC/Renesas uPD720200(A) USB3 controller in Windows, but not so
on any Linux kernels that I've tried (all mainline).
Today I've built 3.8.6, enabled debugging and usbmon, and I've captured
lspci, lsusb, dmesg and usbmon (both text and wireshark) data here:
http://dx.infernix.net/renesas/
Device insertion happens around the 21:50:15 mark, and isn't removed
during the logs. Some excerpts in no specific order:
Apr 9 21:50:16 believe kernel: sd 7:0:0:0: [sdc] 976773168 512-byte
logical blocks: (500 GB/465 GiB)
..
Apr 9 21:50:16 believe kernel: xhci_hcd :07:00.0: WARN halted
endpoint, queueing URB anyway.
These messages appear to be bugs, either in the xHCI hardware or in the
driver. They appear immediately after the endpoint halt was cleared,
so they are obviously wrong.
..
Apr 9 21:50:59 believe kernel: xhci_hcd :07:00.0: Stalled endpoint
..
Apr 9 21:51:30 believe udevd[23487]: timeout: killing '/sbin/blkid -o
udev -p /dev/sdc' [23924]
..
Apr 9 21:52:52 believe kernel: usb 4-2: device not accepting address 6,
error -22
..
Apr 9 21:52:54 believe kernel: hub 4-0:1.0: logical disconnect on port 2
..
Apr 9 21:52:54 believe kernel: usb-storage: usb_stor_post_reset
It constantly cycles into resets.
That appears to be the real problem. I can't tell what's going on but
maybe Sarah can.
Sarah, look at what the dmesg log says around timestamp 21:51:00:
Apr 9 21:51:00 believe kernel: xhci_hcd :07:00.0: Port Status Change Event
for port 2
Apr 9 21:51:00 believe kernel: xhci_hcd :07:00.0: handle_port_status:
starting port polling.
Apr 9 21:51:00 believe kernel: hub 4-0:1.0: state 7 ports 2 chg evt 0004
Apr 9 21:51:00 believe kernel: xhci_hcd :07:00.0: get port status, actual
port 1 status = 0x202c0
Apr 9 21:51:00 believe kernel: xhci_hcd :07:00.0: Get port status returned
0x102c0
Apr 9 21:51:00 believe kernel: xhci_hcd :07:00.0: clear port connect
change, actual port 1 status = 0x2c0
Apr 9 21:51:00 believe kernel: hub 4-0:1.0: warm reset port 2
Apr 9 21:51:00 believe kernel: usb-storage: usb_stor_pre_reset
Apr 9 21:51:00 believe kernel: xhci_hcd :07:00.0: xhci_hub_status_data:
stopping port polling.
Apr 9 21:51:00 believe kernel: xhci_hcd :07:00.0: Port Status Change Event
for port 2
Apr 9 21:51:00 believe kernel: xhci_hcd :07:00.0: handle_port_status:
starting port polling.
Apr 9 21:51:30 believe kernel: usb-storage: command_abort called
What's up with all that? The port polling persists for 30 seconds
because usb-storage's pre_reset routine has to wait for the current
command to finish, and the command doesn't finish until there's either
an error or a timeout. In this case the command timed out -- that's
the reason for the 30-second delay.
But why wasn't there an immediate error? Evidently a port-connect
change occurred. It should have caused the bulk-IN URB to complete
right away with an error. After all, how can the device respond to
poll packets if it isn't connected?
We have seen this same problem reported before by other people.
From time to time in previous kernels
I was able to mount it and copy some data, but after seconds of copying
data it would reset and it would lose the SCSI device. With 3.8.6 I
can't even do an fdisk -l /dev/sdc because it will just reset before
that even happens. Plug it into an USB2 port and all is well with the
world. Boot to Windows on USB3 and I can copy data with 100MByte/s to
and from it.
Is this device not working properly in Linux due to lack of vendor
documentation for the USB3 controller, or is something else going on
here? Could someone please shed some light on this?
I don't know the answers, but obviously something is wrong in the
interaction among the driver, the controller, and the device.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
