> Date: Sun, 16 Jan 2011 18:18:19 +0100 > From: Matthieu Herrb <matthieu.he...@laas.fr> > > I redid a make build with just that. It finished ok without errors. > > *but* I noticed about a dozen of error like this one during the build, > concerning random block numbers: > > wd0a: DMA error reading fsbn 12543712 of 12543712-12543743 (wd0 bn 12543712; > cn 3074 tn 7 sn 7), retrying > wd0: soft error (corrected) > > and worse, there were about the same number during the first build > with Brad's full patch. > > A previous build last week with no patches at all caused no > errors. I've restarted a build with no patches to confirm that it's > not dying hw. > > my conclusion for now is that not only is UDMA 4 still not good, but the > patch doesn't make it better.
Thanks Matthieu, As far as I'm concerned the diff that started this thread is off the table for now. Earlier in this thread somebody suggested to restrict the pciide downgrade to Ultra-DMA mode 2 to just the broken Acer Labs controller. That is actually really easy to do. The big question is whether we want to do this just on sparc64 (and add an ugly #ifdef __sparc64__ in otherwise MI code), or if we should do this to all rev 0xc3 Acer Labs M5229 controllers. There is at least one of those on a Pentium III machine that has a disk attached that does Ultra-DMA mode 4 now in dmesglog. Opinions?
