Hoping someone on this list might shed some light on this... I was investigating a problem of poor sequential write performance (IOmeter, various size sequential writes) with an embedded Vitesse 7174, maxing out (with disk write cache on) at around 10 MB/s... After noticing that Windows on the same hardware was using 0x10 for the cache line size, but Linux was using 0x80, I tried removing the following from sata_vsc.c: 381 /* 382 * Due to a bug in the chip, the default cache line size can't be used 383 */ 384 pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, 0x80); Now, with cache line size the same as Windows, Linux is doing more like 43 MB/s. Just wondering what the deal with this "bug in the chip" might be, since for me it seems that the default cache line size is better? If there's a real bug, I don't want to do anything dangerous by removing this code (though I've heard--haven't seen the code--that the Windows driver doesn't touch the cache line size, nor does the Linux non-libata reference driver from Vitesse). Thanks! Nate - 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
