On Tue, Mar 20, 2012 at 07:46:04PM +0100, Daniel Dorau wrote: > Hello, > > I hope you are the right one to ask. I have Thinkpad x220 with Linux > kernel 3.3 and with that kernel, copying large files to USB 3.0 hard > drives via a USB 3.0 hub doesn't work reliably anymore. > > I could transfer a terabyte with Kernel 3.2 that way without any > problems, but with 3.3, it stalls relatively early. By "stall", you mean the transfer stops making progress, correct? Not that the device stalls a particular SCSI command (stall means something technical for mass storage and USB transfers). > When the drive is connected directly to the USB host, I haven't had such > problems yet, which makes me believe that it could be related to the > handling of the USB hub. I see you have a VIA USB 3.0 hub. I haven't had very good luck with that manufacturer of hubs. AFAICT, it seems to be hardware/firmware issues in the device and not software issues. I could be wrong, but I haven't been able to find anything on the software side that points to a SW bug. So it's very interesting that you say one particular kernel works over the other. The only USB 3.0 hub commit between 3.2 and 3.3 is a45aa3b30583e7d54e7cf4fbcd0aa699348a6e5c, which actually made the VIA hub work for one person. Plus, that commit should have only touched the paths where the VIA hub needed a reset, and that's not what your log shows. I'm a bit stumped. Maybe there was changes to either the USB storage layer or the SCSI layer that causes your USB device to need a reset? And then the VIA hub can't handle that request? If the crashes are highly reproducible, you could run git bisect between 3.2 and 3.3 to see which commit broke your hub. > The USB root hub is a "NEC Corporation uPD720200 USB 3.0 Host > Controller", the external USB hub is a D-Link Hub (Model DUB-1340). > > This is what dmesg shows: > > [51903.060884] usb 1-1: new high-speed USB device number 3 using xhci_hcd > [51903.079099] usb 1-1: New USB device found, idVendor=2109, idProduct=3431 > [51903.079109] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 > [51903.079114] usb 1-1: Product: USB2.0 Hub > [51903.080163] hub 1-1:1.0: USB hub found > [51903.080504] hub 1-1:1.0: 4 ports detected > [51903.326041] usb 2-1: new SuperSpeed USB device number 5 using xhci_hcd > [51903.628453] usb 2-1: New USB device found, idVendor=2109, idProduct=0810 > [51903.628463] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > [51903.628469] usb 2-1: Product: 4-Port USB 3.0 Hub > [51903.628474] usb 2-1: Manufacturer: VIA Labs, Inc. > [51903.631487] hub 2-1:1.0: USB hub found > [51903.683382] hub 2-1:1.0: 4 ports detected > [51931.367661] usb 2-1.4: new SuperSpeed USB device number 6 using xhci_hcd > [51931.388603] usb 2-1.4: New USB device found, idVendor=1e68, idProduct=004c > [51931.388613] usb 2-1.4: New USB device strings: Mfr=2, Product=3, SerialNumber=1 > [51931.388619] usb 2-1.4: Product: pocket click 3.0 > [51931.388623] usb 2-1.4: Manufacturer: TrekStor DS > [51931.388627] usb 2-1.4: SerialNumber: B00000000000000BC0 > [51931.389952] scsi11 : usb-storage 2-1.4:1.0 > [51934.868426] scsi 11:0:0:0: Direct-Access TrekStor pocket click 3.0 GN00 PQ: 0 ANSI: 5 > [51934.871204] sd 11:0:0:0: [sdb] 1465149168 512-byte logical blocks: (750 GB/698 GiB) > [51934.873020] sd 11:0:0:0: [sdb] Write Protect is off > [51934.873034] sd 11:0:0:0: [sdb] Mode Sense: 23 00 00 00 > [51934.873894] sd 11:0:0:0: [sdb] No Caching mode page present > [51934.873905] sd 11:0:0:0: [sdb] Assuming drive cache: write through > [51934.876012] sd 11:0:0:0: [sdb] No Caching mode page present > [51934.876021] sd 11:0:0:0: [sdb] Assuming drive cache: write through > [51934.899052] sdb: sdb1 sdb2 > [51934.902376] sd 11:0:0:0: [sdb] No Caching mode page present > [51934.902387] sd 11:0:0:0: [sdb] Assuming drive cache: write through > [51934.902392] sd 11:0:0:0: [sdb] Attached SCSI disk > [51936.215431] kjournald starting. Commit interval 5 seconds > [51936.215653] EXT3-fs (sdb1): warning: maximal mount count reached, > running e2fsck is recommended > [51936.216228] EXT3-fs (sdb1): using internal journal > [51936.216234] EXT3-fs (sdb1): mounted filesystem with ordered data mode > [51966.342952] usb 1-1.3: new high-speed USB device number 4 using xhci_hcd > [51966.343455] usb 1-1.3: Device not responding to set address. > [51966.547065] usb 1-1.3: Device not responding to set address. > [51966.750407] usb 1-1.3: device not accepting address 4, error -71 > [51966.767235] hub 1-1:1.0: unable to enumerate USB device on port 3 > [51967.111384] usb 2-1.3: new SuperSpeed USB device number 7 using xhci_hcd > [51967.129904] usb 2-1.3: New USB device found, idVendor=18a5, idProduct=022e > [51967.129910] usb 2-1.3: New USB device strings: Mfr=10, Product=11, SerialNumber=3 > [51967.129914] usb 2-1.3: Product: Portable USB 3.0 Drive > [51967.129917] usb 2-1.3: Manufacturer: Verbatim > [51967.129920] usb 2-1.3: SerialNumber: 200513111728 It looks like the USB 3.0 device disconnected and then reconnected. There's not much I can do to fix that. I'm not sure what changes from 3.2 to 3.3 would make the USB 3.0 hub report a disconnect. Can you turn on CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING for 3.3 and send the dmesg to me (as a separate attachment, since your mailer seems to wrap lines)? Maybe there's something I'm missing from the standard log messages. > [51967.130956] scsi12 : usb-storage 2-1.3:1.0 > [51968.130400] scsi 12:0:0:0: Direct-Access TOSHIBA MK1059GSM 0100 PQ: 0 ANSI: 2 CCS > [51968.133341] sd 12:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) > [51968.134015] sd 12:0:0:0: [sdc] Write Protect is off > [51968.134027] sd 12:0:0:0: [sdc] Mode Sense: 28 00 00 00 > [51968.134743] sd 12:0:0:0: [sdc] No Caching mode page present > [51968.134750] sd 12:0:0:0: [sdc] Assuming drive cache: write through > [51968.136716] sd 12:0:0:0: [sdc] No Caching mode page present > [51968.136724] sd 12:0:0:0: [sdc] Assuming drive cache: write through > [51968.168497] sdc: sdc1 > [51968.170816] sd 12:0:0:0: [sdc] No Caching mode page present > [51968.170825] sd 12:0:0:0: [sdc] Assuming drive cache: write through > [51968.170831] sd 12:0:0:0: [sdc] Attached SCSI disk > [51968.823794] kjournald starting. Commit interval 5 seconds > [51968.825216] EXT3-fs (sdc1): using internal journal > [51968.825224] EXT3-fs (sdc1): mounted filesystem with ordered data mode > [52032.465453] keyboard: can't emulate rawmode for keycode 240 > [52032.465467] keyboard: can't emulate rawmode for keycode 240 And then the VIA hub didn't respond to a request to reset the port. The xHCI host controller reported the status as -71, which is a -EPROTO, which indicates a transfer error. I would love to see exactly which command the VIA hub choked on. Can you run USBmon and send me the output around the time the transfer fails? > [65662.511862] hub 2-1:1.0: cannot reset port 3 (err = -71) > [65662.512107] hub 2-1:1.0: cannot reset port 3 (err = -71) > [65662.512349] hub 2-1:1.0: cannot reset port 3 (err = -71) > [65662.512717] xhci_hcd 0000:0e:00.0: URB transfer length is wrong, xHC > issue? req. len = 0, act. len = 4294967288 Hmm, that message is interesting. It means the host controller reported the wrong length for a transfer. > [65662.714509] hub 2-1:1.0: hub_port_status failed (err = -71) > [65662.714878] hub 2-1:1.0: cannot reset port 3 (err = -71) > [65662.714884] hub 2-1:1.0: Cannot enable port 3. Maybe the USB cable is bad? > [65662.715270] hub 2-1:1.0: cannot reset port 3 (err = -71) > [65662.715617] hub 2-1:1.0: cannot reset port 3 (err = -71) > [65662.715863] hub 2-1:1.0: cannot reset port 3 (err = -71) > [65662.716093] hub 2-1:1.0: cannot reset port 3 (err = -71) > [65662.716337] hub 2-1:1.0: cannot reset port 3 (err = -71) > [65662.716343] hub 2-1:1.0: Cannot enable port 3. Maybe the USB cable > is bad? And then the transfer errors continue until the SCSI core gives up on the device. > As said before, this has worked well with Kernel 3.2. > > I hope the log above gives a hint what the issue could be. If you need > more information, please let me know. I would say start with turning on USB and xHCI debugging, run `sudo dmesg -n 8`, and then send the full log file to me. After you've confirmed it still crashes, use USBmon (Documentation/usb/usbmon.txt) to capture the transfers after the device reconnects. Maybe the hub always stalls after a particular command. Once you've done that, you might want to bisect between 3.2 and 3.3 to see exactly which commit causes your issues. Sarah Sharp -- 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
