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
