On 12/20/2012 02:54 AM, bl0 wrote:
On Wednesday 19 December 2012 04:44, Robert Hancock wrote:
On 12/18/2012 09:23 AM, bl0 wrote:
Do you think something should be done about it in the linux sata_sil
driver? For a lack of a better solution, here is my suggestion. There is
already one option 'slow_down' for problematic disks. Another option, for
example 'cache_line_workaround', could be added for problematic
motherboards. If enabled, the most straightforward way is to set cache
line size to 0 and not worry about the fifo_cfg register. If someone else
confirms that it solves the problem for them, this option could be
enabled automatically if certain motherboard chipset is detected.
We'd have to somehow narrow down which chipsets were involved, which
might be a hard task. Do you have an idea of how much the performance is
hurt by these workarounds? If it's not a lot, it might make sense to do
it by default.
After setting cache line size to 0, write speed as shown by 'dd
if=/tmpfs/testfile of=/dev/sdc9 bs=1M count=256' goes down from about
45 MB/s to 17 MB/s. Personally I don't care about performance, reliability
and data safety are more important to me.
Yeah, cutting performance by 2/3rds is fairly bad though.
The other workaround is to increase cache line size to 64 bytes, if
necessary, and set fifo_cfg to 0. No difference in performance measured.
This workaround is more of a hit or miss. It seems to contradict that code
commit made back in 2005, which was also about data corruption. In the
worst case, what solves data corruption problem on some motherboards might
introduce this problem on some other motherboards.
That's possible, which is why I suspect that someone from Silicon Image
would have to confirm a possible fix - might be hard to get their
attention about this old chipset..
--
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
