It's now clear that this is _not_ an XHCI issue, contrary to what $SUBJECT says. On Thu, 16 Jan 2014, Peter Palúch wrote: > Alan, > > I am attaching the usbmon trace after the drive has been plugged into > the USB-2 port. Record of the drive in stall should occur around the > file offset 87808 (decimal). The log was done on the 3.12.7 kernel > without CONFIG_PM. Should I do a usbmon trace on my regular kernel with > CONFIG_PM as well? No need. > dmesg transcript: > > root@bach:/tmp# dmesg > usb 4-1.2: new high-speed USB device number 5 using ehci-pci > usb 4-1.2: New USB device found, idVendor=1058, idProduct=1230 > usb 4-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1 > usb 4-1.2: Product: My Book 1230 > usb 4-1.2: Manufacturer: Western Digital > usb 4-1.2: SerialNumber: 574D43344E30323438393836 > usb-storage 4-1.2:1.0: USB Mass Storage device detected > scsi6 : usb-storage 4-1.2:1.0 > usbcore: registered new interface driver usb-storage > scsi 6:0:0:0: Direct-Access WD My Book 1230 1050 PQ: 0 ANSI: 6 > scsi 6:0:0:1: Enclosure WD SES Device 1050 PQ: 0 ANSI: 6 > sd 6:0:0:0: Attached scsi generic sg2 type 0 > scsi 6:0:0:1: Attached scsi generic sg3 type 13 > sd 6:0:0:0: [sdb] Spinning up disk... > .........ready > sd 6:0:0:0: [sdb] 732558336 4096-byte logical blocks: (3.00 TB/2.72 TiB) > sd 6:0:0:0: [sdb] Write Protect is off > sd 6:0:0:0: [sdb] Mode Sense: 53 00 10 08 > sd 6:0:0:0: [sdb] No Caching mode page found > sd 6:0:0:0: [sdb] Assuming drive cache: write through > sd 6:0:0:0: [sdb] 732558336 4096-byte logical blocks: (3.00 TB/2.72 TiB) > sd 6:0:0:0: [sdb] No Caching mode page found > sd 6:0:0:0: [sdb] Assuming drive cache: write through > sdb: sdb1 > sd 6:0:0:0: [sdb] 732558336 4096-byte logical blocks: (3.00 TB/2.72 TiB) > sd 6:0:0:0: [sdb] No Caching mode page found > sd 6:0:0:0: [sdb] Assuming drive cache: write through > sd 6:0:0:0: [sdb] Attached SCSI disk > usb 4-1.2: reset high-speed USB device number 5 using ehci-pci It looks like the reset occurred because the computer sent an ATA-passthru command to the disk, and the disk wasn't prepared to handle it properly. The firmware crashed, requiring a reset. If anyone can explain, the command bytes in question were: 85082e00 00000000 00000000 0000ec00 and the sense data was: 7201001d 0000000e 090c0000 00005d00 01000000 0050 I don't know what either of these means, or even what software was responsible for sending this command. It appears to have come from some user program, though, not the kernel. Possibly something run by udev. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
