On Sat, 2009-01-10 at 12:21 +0000, Alan Cox wrote: > > That's the typical REQUEST SENSE command with 18-byte data length. > > Which means something has become horribly broken in the core libata stack. > An 18 byte inquiry would have 18 bytes as the *last* sg element. That > would therefore not trigger the WARN_ON. Someone has passed an sg list > that isn't properly terminated perhaps ? > > I wonder if the pad code broke this. I don't think it's anything to do with padding or the block layer. I think we sent out a request sense with 96 bytes of space for a reply, which is bog standard for SCSI. The device sent back a payload of 18 bytes, which is perfectly legal ... request sense is a variable payload command, the device doesn't have to fill the buffer we give it. 18, by the way, is the typical reply length for non descriptor sense format with no additional information, so this is really expected behaviour. Your problem is that the *device* is wanting to transfer a set of bytes not divisible by four. If you want to use word based PIO, you'll have to fall back to collecting bytes for the last two. Alternatively, you could just do byte PIO for all reply lengths like this ... they occur all over the SCSI standard, but not usually in critical paths. James -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
