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 0000: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 0000: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 0000:07:00.0: Port Status Change Event for port 2 Apr 9 21:51:00 believe kernel: xhci_hcd 0000: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 0000 evt 0004 Apr 9 21:51:00 believe kernel: xhci_hcd 0000:07:00.0: get port status, actual port 1 status = 0x202c0 Apr 9 21:51:00 believe kernel: xhci_hcd 0000:07:00.0: Get port status returned 0x102c0 Apr 9 21:51:00 believe kernel: xhci_hcd 0000: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 0000:07:00.0: xhci_hub_status_data: stopping port polling. Apr 9 21:51:00 believe kernel: xhci_hcd 0000:07:00.0: Port Status Change Event for port 2 Apr 9 21:51:00 believe kernel: xhci_hcd 0000: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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
