On 01/16/2014 09:48 PM, Alan Stern wrote: > 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. > Probably smartd. The logic there is _less_ than perfect. Try to disable smartd and check if the issue remains. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
