> We are both half-right. I reverted my version of that completely, > applied your version verbatim, and pushed it upstream. The result: > atapi_xlat _did_ start programming lbam/lbah for DMA (another behavior > change), but request-sense DMA path was not changed to program lba[mh] > for DMA. I didn't realise we ever issued reques sense by DMA ? > > Only if your transfer is actually 8K or more. > > No, that's precisely the problem cause for what Daniel is reporting. We > are setting blimit=xfer_len(==10), when the device wants to return more > than 10 bytes. When set to the old limit (8k), the problem didn't occur. Lots of *other* problems occur instead. Daniel is reporting that if he makes a stupid request to a buggy drive he gets a reset and the system continues happily. Even that reset being a reset not a new command issue is actually us being excessively paranoid. Prior to these changes people were reporting things like "I cannot use my CD-ROM". So given we have ten years of experience of the method I put in taken from the old IDE layer versus a good way to make one buggy request work and break everything else - I *know* which I consider to be the right path. And PIO drains of DMA controllers do not work for most controllers, some will simply hang solid if you touch the data register as part of a DMA sequence (eg promise 2026x) Alan - 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
