On 2007.01.19 20:41:36 -0600, Robert Hancock wrote: > Alistair John Strachan wrote: > >On Tuesday 16 January 2007 01:53, Jeff Garzik wrote: > >>Robert Hancock wrote: > >>>I'll try your stress test when I get a chance, but I doubt I'll run into > >>>the same problem and I haven't seen any similar reports. Perhaps it's > >>>some kind of wierd timing issue or incompatibility between the > >>>controller and that drive when running in ADMA mode? I seem to remember > >>>various reports of issues with certain Maxtor drives and some nForce > >>>SATA controllers under Windows at least.. > >>Just to eliminate things, has disabling ADMA been attempted? > >> > >>It can be disabled using the sata_nv.adma module parameter. > > > >Setting this option fixes the problem for me. I suggest that ADMA defaults > >off in 2.6.20, if there's still time to do that. > > > > Can you guys that are having this problem try the attached debug patch? > It's possible it will fix the problem, as I'm trying a private > exec_command implementation that flushes the write by reading a > controller register instead of reading altstatus from the drive like the > libata core code does.
Will give it a spin in about an hour. > If the problem still happens, I also added some more debugging in to > help figure out what is going on, so please post full dmesg. > > By the way, I assume that you guys are using reiserfs or xfs, as it > appears no other file systems issue flush commands automatically. I had > to test this by "echo 1 > delete" on the SCSI disk in sysfs, as I am > using ext3. No, ext3 here, on top of md RAID1 and LVM. Oh, and one ext2, I wonder where that comes from... Björn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
