* Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device [not found] <52D8376E.1090805@fri.uniza.sk> @ 2014-01-16 20:48 ` Alan Stern 2014-01-17 7:35 ` Hannes Reinecke 0 siblings, 1 reply; 7+ messages in thread From: Alan Stern @ 2014-01-16 20:48 UTC (permalink / raw) To: Peter Palúch; +Cc: linux-usb@vger.kernel.org, SCSI development list 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device 2014-01-16 20:48 ` XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device Alan Stern @ 2014-01-17 7:35 ` Hannes Reinecke [not found] ` <52D8DD45.9010602-l3A5Bk7waGM@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: Hannes Reinecke @ 2014-01-17 7:35 UTC (permalink / raw) To: Alan Stern, Peter Palúch Cc: linux-usb@vger.kernel.org, SCSI development list 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@suse.de +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-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <52D8DD45.9010602-l3A5Bk7waGM@public.gmane.org>]
* Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device [not found] ` <52D8DD45.9010602-l3A5Bk7waGM@public.gmane.org> @ 2014-01-17 20:25 ` Douglas Gilbert [not found] ` <52D991BA.40903-qazKcTl6WRFWk0Htik3J/w@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: Douglas Gilbert @ 2014-01-17 20:25 UTC (permalink / raw) To: Hannes Reinecke, Alan Stern, Peter Palúch Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, SCSI development list, Christian Franke 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] -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <52D991BA.40903-qazKcTl6WRFWk0Htik3J/w@public.gmane.org>]
* Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device [not found] ` <52D991BA.40903-qazKcTl6WRFWk0Htik3J/w@public.gmane.org> @ 2014-01-17 21:14 ` Peter Palúch 2014-01-18 14:12 ` Christian Franke 0 siblings, 1 reply; 7+ messages in thread From: Peter Palúch @ 2014-01-17 21:14 UTC (permalink / raw) To: dgilbert-qazKcTl6WRFWk0Htik3J/w, Hannes Reinecke, Alan Stern Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, SCSI development list, Christian Franke 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device 2014-01-17 21:14 ` Peter Palúch @ 2014-01-18 14:12 ` Christian Franke 2014-01-18 15:02 ` Peter Palúch 2014-01-19 0:27 ` Peter Palúch 0 siblings, 2 replies; 7+ messages in thread From: Christian Franke @ 2014-01-18 14:12 UTC (permalink / raw) To: Peter Palúch, dgilbert Cc: Hannes Reinecke, Alan Stern, linux-usb@vger.kernel.org, SCSI development list 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 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.] >> 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 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. 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-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device 2014-01-18 14:12 ` Christian Franke @ 2014-01-18 15:02 ` Peter Palúch 2014-01-19 0:27 ` Peter Palúch 1 sibling, 0 replies; 7+ messages in thread From: Peter Palúch @ 2014-01-18 15:02 UTC (permalink / raw) To: Christian Franke, dgilbert Cc: Hannes Reinecke, Alan Stern, linux-usb@vger.kernel.org, SCSI development list 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device 2014-01-18 14:12 ` Christian Franke 2014-01-18 15:02 ` Peter Palúch @ 2014-01-19 0:27 ` Peter Palúch 1 sibling, 0 replies; 7+ messages in thread From: Peter Palúch @ 2014-01-19 0:27 UTC (permalink / raw) To: Christian Franke, dgilbert Cc: Hannes Reinecke, Alan Stern, linux-usb@vger.kernel.org, SCSI development list 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 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.] >>> > > 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 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. > > 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-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-01-19 0:27 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <52D8376E.1090805@fri.uniza.sk>
2014-01-16 20:48 ` XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device Alan Stern
2014-01-17 7:35 ` Hannes Reinecke
[not found] ` <52D8DD45.9010602-l3A5Bk7waGM@public.gmane.org>
2014-01-17 20:25 ` Douglas Gilbert
[not found] ` <52D991BA.40903-qazKcTl6WRFWk0Htik3J/w@public.gmane.org>
2014-01-17 21:14 ` Peter Palúch
2014-01-18 14:12 ` Christian Franke
2014-01-18 15:02 ` Peter Palúch
2014-01-19 0:27 ` Peter Palúch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox