On Mon, Apr 12, 2010 at 09:48:25AM +0200, Jonas Schwertfeger wrote: > On 04/09/2010 11:54 PM, Sarah Sharp wrote: > >>Now that you mention it, we don't know what sort of chip you have. > >>Only that the vendor ID is 0x0411 (MelCo., Inc.) and the product ID is > >>0x0184. > > Buffalo is part of the MelCo Inc. holding. > > >I've just opened the case on my Buffalo hard drive, and the circuit just > >says Buffalo. There's an ARM chip and a winbond chip, but not much else > >to identify it. I'll ask around the USB-IF PIL lab to try and get a > >company contact. > > The ARM chip in the Buffalo USB3 drive is the USB3-SATA bridge > MB86C30A by Fujitsu: http://www.fujitsu.com/downloads/EDG/binary/pdf/catalogs/a04000431e.pdf > > My guess would be that any drive using this chip will choke on the > identify command. Sarah, any chance you could get a contact at > Fujitsu? I'll see if I can find a contact for this. I need a couple more details so they can reproduce this. Jonas, did you ever test the Buffalo drive with Mark Lord's fix to set the sector count to "1"? Which version of hdparm were you using? Is that version just in Lucid, or is it in Karmic too? In the meantime, can everyone confirm my summary of the behavior of the Buffalo device (not the Genesys chip)? There seems to be an issue with how the Buffalo USB3 hard drive handles the SCSI ATA pass through commands. We found this issue when the Linux userspace program hdparm, using the Ubuntu Linux distribution. The device responds correctly to an IDENTIFY DEVICE via the ATA_12 tunnel, but it stalls when it's sent an IDENTIFY DEVICE via the ATA_16 tunnel. 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 problem makes the device unusable under the Linux 2.6.31 and 2.6.32 kernels, as they don't support configured device reset after an endpoint stall. The device works on later kernels (2.6.33 and 2.6.34) with that support. Details ------- The hdparm program issues the following commands, and gets the following responses: command contents: a1 08 2e 00 01 00 00 00 00 ec 00 00 Bulk Command S 0x43425355 T 0x2d L 512 F 128 Trg 0 LUN 0 CL 12 Bulk Status S 0x53425355 T 0x2d R 0 Stat 0x0 scsi cmd done, result=0x0 (This is an IDENTIFY DEVICE via the ATA_12 tunnel) command contents: 85 06 20 00 05 00 fe 00 00 00 00 00 00 40 ef 00 Bulk Command S 0x43425355 T 0x2e L 0 F 0 Trg 0 LUN 0 CL 16 Bulk Command S 0x43425355 T 0x2f L 512 F 128 Trg 0 LUN 0 CL 16 Bulk Status S 0x53425355 T 0x2e R 0 Stat 0x0 scsi cmd done, result=0x0 (This is a SET FEATURES via the ATA_16 tunnel) command contents: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00 Bulk Command S 0x43425355 T 0x2f L 512 F 128 Trg 0 LUN 0 CL 16 Bulk Status S 0x53425355 T 0x2f R 512 Stat 0x2 Status code -32; transferred 0/512 clearing endpoint halt for pipe 0xc0008280 Bulk status result = 0 Bulk Status S 0x53425355 T 0x2f R 512 Stat 0x2 -- transport indicates error, resetting (This is an IDENTIFY DEVICE via the ATA_16 tunnel) The full log is here: http://minilop.net/~sarah/buffalo-hd-ata-16-issue.log The drive stalls on the last command, which is a valid ATA command. Can you confirm if your device supports the SCSI ATA pass through specification? http://www.t10.org/cgi-bin/ac.pl?t=f&f=sat2r09.pdf Sarah Sharp -- 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
