On Sunday 16 January 2011 16:44:47 Mark Kettenis wrote: > > 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?
I have no issue which particular workaround is used as long as something is done in the pciide(4) driver instead of the kernel config. I had no knowledge that a similar diff had been tested in private before otherwise I wouldn't have posted it in the first place and would have gone down the route of restricting the Ultra-DMA mode allowed to be used within the driver for that particular revision. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
