Gentlemen,
First of all, thank you very much for looking into this issue.
Alan, for the sake of keeping the thread tidy in archives, I am not
going to change the $SUBJECT of this e-mail but I wholeheartedly agree
that this is not an xHCI issue. Mea culpa; I did not know that at the
time I first reported it.
Douglas, Hannes: I believe we are definitely on to something. I do _not_
run smartd but this may be caused by something in my Gnome3 GUI
environment. I have noticed that when I am not logged in to Gnome and
work just in the text console, plugging in the USB drive and accessing
it works without any issues. Only when I am logged into my Gnome and
plug the drive in, Gnome obviously tries to do something with the drive
that causes it to stall and recover in 30 seconds. I have not yet been
able to identify what it is.
I am not subscribed to linux-scsi mailing list so if you believe
anything of this is relevant please forward that mail there.
Thank you!
Best regards,
Peter
On 17.01.2014 21:25, Douglas Gilbert wrote:
On 14-01-17 02:35 AM, Hannes Reinecke wrote:
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
SCSI ATA PASS-THROUGH(16) command issuing the
mandatory ATA command 0xec which is IDENTIFY DEVICE.
[See SAT-3 drafts for more information on the pass-through
command.]
and the sense data was:
7201001d 0000000e 090c0000 00005d00 01000000 0050
ATA spec says there should not (normally) be an error issued
by that command; but there was:
$ sg_decode_sense -n 7201001d 0000000e 090c0000 00005d00 01000000 0050
Descriptor format, current; Sense key: Recovered Error
Additional sense: ATA pass through information available
Descriptor type: ATA Status Return
extend=0 error=0x0 sector_count=0x0
lba=0x000000
device=0x0 status=0x50
Looks reasonable at the SCSI level, not sure about the
ATA level, perhaps others can comment.
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.
Guilty as charged. Silly us, fancy smartmontools issuing
mandatory ATA commands over a USB transport (MSC ?) and
expecting the device to be well-behaved :-)
Try to disable smartd and check if the issue remains.
Probably will help. Throwing away all your USB storage
devices (apart from those that do UAS(P)) would be even
more helpful (to us).
Perhaps smartmontools could do a better job of identifying
USB connected storage devices and avoid them.
Doug Gilbert
[a smartmontools maintainer]
--
Ing. Peter Palúch, Ph.D.
CCIE R&S #23527, CCIP, CCAI, Cisco Designated VIP 2011-2014 LAN & WAN
Department of InfoCom Networks
Faculty of Management Science and Informatics, University of Zilina
Univerzitná 8215/1, 010 26 Žilina, Slovakia
WWW: http://www.kis.fri.uniza.sk
Tel.: +421-41-513-4325, +421-905-164432
--
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
