Mark Lord wrote:
Workaround for errata SATA#24 in sata_mv.
This errata affects WRITE_MULTI* commands when
the device multi_count produces a DRQ block size >= 4Kbytes.
We work around it here by converting such operations
into ordinary PIO_WRITEs instead.
Note that this might result in a PIO FUA write unavoidably being converted
into a non-FUA write. In practice, any system using FUA is also going to be
using DMA rather than PIO, so this shouldn't affect anyone in the real world.
..
Testing this was a real bear.
The drives I have here are among those which cannot do R/W MULTI
prior to having a SET_MULTIPLE command issued to them by libata.
Which libata currently does not do.
This means that libata is unable to cope with non-DMA devices
that report a non-zero multi_count value at startup.
I simulated this scenario in sata_mv by changing the .udma_mask field
to zero for the card under test. System sat there retrying the
partition table read over and over and over and over.. :)
Someday I'll fix that, if you guys don't beat me to it.
I suppose we just need to issue the SET_MULTIPLE command from
the drive revalidation code.
Cheers
--
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
