On Fri, 2010-04-02 at 19:50 +0400, Sergei Shtylyov wrote: > Hello. > > Alan Stern wrote: > > >>> Best guess (and it's a guess only) would be that the USB bridge SAT > >>> layer doesn't implement ATA_16 and so fails in interesting ways when it > >>> comes in. Does the ATA_12 version of IDENTIFY DEVICE succeed? > >>> > >> It does. And in between the two is an ATA_16 SET FEATURES command > >> which also (apparently) succeeds. That is, there is no error > >> indication from the device -- but goodness knows if it actually carries > >> out the command. > >> > > > > Incidentally, there's a discussion of this problem with input from an > > engineer at the company that makes the bridge chip here: > > > > https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/431963 > > > > See comment #25 and later. He claims that the ATA pass-through command > > contains a SECTOR COUNT field of 0 even though it asks for 512 bytes of > > IDENTIFY data. This invalid parameter combination causes the bridge > > chip to get confused, and instead of failing gracefully, it messes up > > the USB protocol. > > > > IDENTIFY DEVICE command always returns 512 bytes of data, regardless > of any value in the sector count register. > > > Does anybody know where to find out why hdparm is sending an IDENTIFY > > command with invalid parameters? > > > > IDENTIFY DEVICE command has *no* parameters. Alan was talking about ATA_16, which has to contain payload data in SCSI format for the encapsulation to work, so for a command that returns 512b the ATA_16 has to contain this as the data length. Sounds like a Mark Lord problem to me ... cc added. James -- 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
