Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
Gentlemen, I believe I've found the root cause of the issue. USB is absolutely not to blame in this case. Problems were caused by the udisksd daemon that sent ATA IDENTIFY DEVICE pass through command with the SECTOR_COUNT field set to 0 (cdb[6] = 0). I first noticed it when I compared the strace output from udiskd to the strace of smartctl and sg_sat_identify - both these tools set the cdb[6] to 1. After correcting the udiskd sources in this aspect, the problem appears to be solved. My sincere thanks to all of you - all your suggestions and comments moved me in the right direction. I will report this issue to udiskd maintainers along with the (trivial) patch. Once again, thanks! Best regards, Peter On 18.01.2014 15:12, Christian Franke wrote: Peter Palúch wrote: 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. Gnome disk utility? AFAIK it relies on libatasmart. The source code of libatasmart is unrelated to smartmontools. 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 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 ec00 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.] The above command sets CK_COND bit (CDB[2] |= 0x20) to request ATA return descriptor. Smartmontools never set CK_COND for IDENTIFY DEVICE. It is only set if ATA output reqister values are actually needed: # smartctl -d sat -r ioctl -i -H /dev/sdd ... REPORT-IOCTL: Device=/dev/sdd Command=IDENTIFY DEVICE Input: FR=, SC=0x01, LL=, LM=, LH=, DEV=, CMD=0xec IN [ata pass-through(16): 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 ec 00 ] ... REPORT-IOCTL: Device=/dev/sdd Command=SMART STATUS CHECK Input: FR=0xda, SC=, LL=, LM=0x4f, LH=0xc2, DEV=, CMD=0xb0 [ata pass-through(16): 85 06 2c 00 da 00 00 00 00 00 4f 00 c2 00 b0 00 ] ... and the sense data was: 7201001d 000e 090c 5d00 0100 0050 ATA spec says there should not (normally) be an error issued by that command; but there was: $ sg_decode_sense -n 7201001d 000e 090c 5d00 0100 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=0x00 device=0x0 status=0x50 Looks reasonable at the SCSI level, not sure about the ATA level, perhaps others can comment. Returned ATA register values look reasonable but are not needed for ATA IDENTIFY command. Doug Gilbert [a smartmontools maintainer] Christian Franke [a smartmontools maintainer :-] -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
Christian, 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. Gnome disk utility? AFAIK it relies on libatasmart. The source code of libatasmart is unrelated to smartmontools. I am not intentionally starting or running any disk utility when plugging the USB disk to my notebook. I am simply logged to Gnome3, have my terminal window open, plug in the disk - and voila, I can be sure that within 30 seconds, I get a dmesg log about the drive being reset, without even calling the gdisk utility I've been using earlier (note - no change of behavior here, it was just me trying to work with the drive right after it was recognized, which obviously coincided with some Gnome subsystem trying to lay its hands on the drive as well - perhaps the automount, udisksd, or something else). I will try to find out what exactly is fired up in Gnome when I plug in the drive, and will update this thread as soon as I have something new. Best regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
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 ec00 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 000e 090c 5d00 0100 0050 ATA spec says there should not (normally) be an error issued by that command; but there was: $ sg_decode_sense -n 7201001d 000e 090c 5d00 0100 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=0x00 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 Desig
Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
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? 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 Thank you! Best regards, Peter On 15.01.2014 18:30, Alan Stern wrote: On Wed, 15 Jan 2014, Peter Palúch wrote: The interesting thing is that the same happens even if the drive is plugged into an USB 2.0 port in the same notebook: That is an important point. Can you post a usbmon trace similar to the earlier one, but with the drive plugged into the USB-2 port? usbmon-2.0.txt.bz2 Description: application/bzip
Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
ached SCSI disk root@bach:~# time gdisk -l /dev/sdb GPT fdisk (gdisk) version 0.8.8 Partition table scan: MBR: not present BSD: not present APM: not present GPT: not present Creating new GPT entries. Disk /dev/sdb: 732558336 sectors, 2.7 TiB Logical sector size: 4096 bytes Disk identifier (GUID): E2D26EE9-FC4F-49C8-94A7-92B599334779 Partition table holds up to 128 entries First usable sector is 6, last usable sector is 732558330 Partitions will be aligned on 256-sector boundaries Total free space is 732558325 sectors (2.7 TiB) Number Start (sector)End (sector) Size Code Name real0m31.631s user0m0.008s sys0m0.002s root@bach:~# dmesg usb 3-1.1: reset high-speed USB device number 5 using ehci-pci root@bach:~# time gdisk -l /dev/sdb GPT fdisk (gdisk) version 0.8.8 Partition table scan: MBR: not present BSD: not present APM: not present GPT: not present Creating new GPT entries. Disk /dev/sdb: 732558336 sectors, 2.7 TiB Logical sector size: 4096 bytes Disk identifier (GUID): 0230C34F-1D95-4710-BFA3-2D016E495FD2 Partition table holds up to 128 entries First usable sector is 6, last usable sector is 732558330 Partitions will be aligned on 256-sector boundaries Total free space is 732558325 sectors (2.7 TiB) Number Start (sector)End (sector) Size Code Name real0m0.015s user0m0.009s sys0m0.003s root@bach:~# Any ideas or suggestions? Thank you very much! Best regards, Peter On 14.01.2014 18:07, Alan Stern wrote: On Tue, 14 Jan 2014, Peter Palúch wrote: Dear friends, So far, there has been no response to this issue report. I understand this is not a help desk with guaranteed replies but the fact that there was no response whatsoever is surprising to me. This means that nobody who has looked at your information knows what the problem is. I would like to at least kindly ask that someone looks at the traces and tells me if this is a possible software issue, or a hardware quirk that can hardly be worked around. A "no, we won't fix this" or even "this is not the proper mailing list for this" type of answer would be welcome at this point. It is kind of frustrating to report an USB-related issue to linux-usb mailing list, keep it updated, and yet receive absolutely no reaction in almost a month. If I knew how to fix this, I would - but I am no expert in USB stuff myself, so I am turning to experts... Nothing stands out in the logs. It may be a power management issue. Have you tried using a kernel with CONFIG_PM not set? Alan Stern config.gz Description: GNU Zip compressed data
Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
Dear friends, So far, there has been no response to this issue report. I understand this is not a help desk with guaranteed replies but the fact that there was no response whatsoever is surprising to me. I would like to at least kindly ask that someone looks at the traces and tells me if this is a possible software issue, or a hardware quirk that can hardly be worked around. A "no, we won't fix this" or even "this is not the proper mailing list for this" type of answer would be welcome at this point. It is kind of frustrating to report an USB-related issue to linux-usb mailing list, keep it updated, and yet receive absolutely no reaction in almost a month. If I knew how to fix this, I would - but I am no expert in USB stuff myself, so I am turning to experts... Thanks for understanding! Best regards, Peter On 08.01.2014 16:48, Peter Palúch wrote: Greetings, Regarding the issue with WD MyBook 1230 stalling and being reset when connected to an HP EliteBook 8560p, I have tested the 3.13-rc7 kernel from kernel.org to no avail - the drive still stalls and is reset after a couple of seconds. I am attaching a dmesg output (relevant lines regarding the drive and the xHCI reset are at the end) and the usbmon trace. The lspci and lsusb outputs have been attached to the original mail I've opened this thread with (if necessary, I will gladly repost them). The usbmon trace covers the complete session with the drive, starting with its connection to my USB 3.0 slot, then accessing the drive with "gdisk -l /dev/sdb", across its stall and reset, up to its physical disconnection. The actual transcript of the communication with the drive that ensued after the "gdisk -l /dev/sdb" command that led to the stall starts at the decimal offset 82582 in the usbmon trace file. Thank you! Best regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
Greetings, Regarding the issue with WD MyBook 1230 stalling and being reset when connected to an HP EliteBook 8560p, I have tested the 3.13-rc7 kernel from kernel.org to no avail - the drive still stalls and is reset after a couple of seconds. I am attaching a dmesg output (relevant lines regarding the drive and the xHCI reset are at the end) and the usbmon trace. The lspci and lsusb outputs have been attached to the original mail I've opened this thread with (if necessary, I will gladly repost them). The usbmon trace covers the complete session with the drive, starting with its connection to my USB 3.0 slot, then accessing the drive with "gdisk -l /dev/sdb", across its stall and reset, up to its physical disconnection. The actual transcript of the communication with the drive that ensued after the "gdisk -l /dev/sdb" command that led to the stall starts at the decimal offset 82582 in the usbmon trace file. Thank you! Best regards, Peter files.tar.bz2 Description: application/bzip
Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
Hi Andrej, Same problem here. HP elitebook 8560w. Running on Arch linux, kernel: 3.12.5. Attaching WD Elements 1TB.no Thanks for confirming that the issue also occurs with HP EliteBook 8560w. Do you believe you could also create the usbmon capture trace plus the outputs of dmesg, lspci and lsusb and post them here? I am quite sure the developers will need to have a look at those. In the meantime, is there any information I can add to my original posting to help identifying the cause of this issue? Best regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
Greetings, I have an HP EliteBook 8560p, I am running Linux kernel 3.12.3, and I am trying to connect a WDC MyBook 1230 3TB SuperSpeed USB hard drive to the notebook. I am often (though not consistently) having problems with the access to the drive stalling for several seconds, and the kernel resetting the device afterwards: usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd xhci_hcd :26:00.0: xHCI xhci_drop_endpoint called with disabled ep 880412adf480 xhci_hcd :26:00.0: xHCI xhci_drop_endpoint called with disabled ep 880412adf4c0 Sometimes a single kernel-issued reset is enough to allow the disk to be accessed without problems until physically disconnected, in another instances, this problem simply repeats itself as the drive is accessed. When the drive decides to cooperate, the transmission speeds are stable and solid - in excess of 120 MB/s. So far, I have not been able to pinpoint the exact circumstances under which the problem remains persistent even across kernel-issued USB resets. I am attaching a series of outputs: - dmesg output after the drive was connected and a "gdisk -l /dev/sdb" command was issued to print out the partition table of the disk, prompting the problem to appear - lspci and lspci -v outputs - lsusb and lsusb -v outputs - usbmon capture, logging the entire session with the drive being connected to the notebook, and issuing "gdisk -l /dev/sdb" command as noted above Any and all help is greatly appreciated! I will gladly perform whatever experiments are necessary to track down the cause of this problem. Best regards, Peter files.tar.bz2 Description: application/bzip
