So what I _really_ want to know is - how the fuck is the actual ATA command itself malformed? You told me at one point that the error code indicated the controller was claiming it overran the end of the sglist - well, if that's the case we ought to be able to prove it with an assertion (I already tried; qc->nbytes does match the sglist, checking from ata_sg_setup()). Ignore bvec merging, PAE, all that crap - the controller doesn't know about any of that. _WHAT_ are we feeding it that it doesn't like? There shouldn't even be that much stuff to check, since in theory the only possible thing that could be at fault is the sglist. Maybe they're too big, too small, misaligned, too many of them, god knows what, but somehow the sglist we're feeding the device has to be at fault, right? But the sglists in Artem's debugging output look pretty uninteresting (one of them has _no_ merged segments - it's just 18 4k pages - how could THAT be an issue?) Gonna apply your debugging patch and start throwing stuff at the wall next, I guess... -- 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
