Re: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device

["Peter Palúch" <Peter.Paluch@fri.uniza.sk>]

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