Re: System hangs when using USB 3.0 HD with on Ubuntu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 19 Apr 2010, Sarah Sharp wrote:

> Updated description
> -------------------
> 
> Summary:
> 
> The Buffalo USB3 hard drive fails to mount after being sent an ATA_16
> IDENTIFY command.  It does not fail when the device is connected via a
> USB 2.0 cable and the same command is sent.

I don't like this summary.  The failure to mount is caused by a defect
in the earlier versions of xhci-hcd (no support for USB port reset),
not by a bug in the drive.  I don't recall seeing a test using the old
version of hdparm and an updated xhci-hcd, but presumably such a 
combination would work okay.

The real problem with the Buffalo drive is that it responds with a
phase error when it receives an ATA_16 IDENTIFY DEVICE command with the
Sector Count field set to 0.

> Details:
> 
> There seems to be an issue with how the Buffalo USB3 hard drive handles
> the SCSI ATA pass through commands.  We found this issue with the Linux
> userspace program hdparm, using the Ubuntu Linux Karmic distribution.
> The device responds correctly to an IDENTIFY DEVICE via the ATA_12
> tunnel, but it responds with a Phase Error when it's sent an IDENTIFY
> DEVICE via the ATA_16 tunnel, and then stalls.

You should not say anything about the drive stalling.  For one thing,
it's misleading: The drive doesn't stall but rather it sends a STALL
token to indicate that the bulk-IN endpoint is halted.  For another,
the STALL is sent _before_ the phase error is reported, not after.  
Lastly, there's absolutely nothing wrong with halting the endpoint like
this; in fact, the Bulk-Only Transport specification requires it under
these circumstances.

> The hdparm program thinks the Phase Error is an invalid response:
> 
> sudo hdparm --verbose /dev/sdb
> 
> /dev/sdb:
> outgoing cdb:  85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00
> SG_IO: ATA_16 status=0x0, host_status=0x7, driver_status=0x0
> SG_IO: bad response (not CHECK_CONDITION)
> outgoing cdb:  85 08 2e 00 00 00 00 00 00 00 00 00 00 40 a1 00
> SG_IO: ATA_16 status=0x0, host_status=0x7, driver_status=0x0
> SG_IO: bad response (not CHECK_CONDITION)
>  HDIO_DRIVE_CMD(identify) failed: Invalid exchange
>  readonly      =  0 (off)
>  readahead     = 256 (on)
>  geometry      = 36365/64/32, sectors = 0, start = 0

Why include two separate commands here?  I thought you were interested
only in the response to the ATA_16 IDENTIFY DEVICE (the first outgoing
cdb above).

> Stalling on the ATA_16 IDENTIFY device is fine, but the invalid response
> is not.

Again, don't mention stalling.  Notice that the information from hdparm
does not show the exact nature of the problem (i.e., that the drive
responded with a phase error), only that a problem occurred.  This 
makes it less useful than you might like.

> The hard drive does not seem to work after this command is sent, and
> cannot be mounted.  If we inhibit udev from running hdparm (by stopping
> the udev daemon) then the drive can be mounted successfully.

First, this is true only if the drive is attached using USB 3.0.  
Second, after this command the drive still works fine -- xhci-hcd is
what doesn't work.

> If the drive is plugged in via a USB 2.0 cable, then the drive works
> correctly, even though it gets issued the same commands.

Right.  That's because the larger problem is in xhci-hcd, not in the
drive.

> The command before the ATA_16 IDENTIFY DEVICE was a SET FEATURES via the
> ATA_16 tunnel, and it was responded to properly, so we think it should
> support the ATA_16 commands.

This is wrong.  The first command shown above is ATA_16 IDENTIFY 
DEVICE.  The second command is ATA_16 IDENTIFY PACKET DEVICE.

To summarize: 0xef is SET FEATURES, 0xec is IDENTIFY DEVICE, and 0xa1 
is IDENTIFY PACKET DEVICE.  The command byte is the second-to-last in 
each cdb.

> The full kernel log is here:
> http://minilop.net/~sarah/buffalo-hd-ata-16-issue.log

I just tried to view that page and got a "403 Forbidden" error.  Does 
it contain the kernel log for the hdparm test shown above, or is it a 
log for a different test?  My guess is that it's a different test -- 
you should mention that fact and describe the commands sent in the 
other test.

> The ATA_12 IDENTIFY command

You mean IDENTIFY DEVICE.  There is no ATA IDENTIFY command.

>  starts at line 8816.  (It says the command
> is a BLANK command, but it's incorrectly identified that command.)

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux