Date: Fri, 3 Feb 95 17:40:45 MST From: terry@cs.weber.edu (Terry Lambert) To: gibbs@estienne.CS.Berkeley.EDU (Justin T. Gibbs) Cc: bugs@warlock.win.net, freebsd-hackers@FreeBSD.org Subject: Re: FIX FOR CACHE/DMA RANGE PROBLEMS (was Re: new SNAP) Message-ID: <9502040040.AA24550@cs.weber.edu> In-Reply-To: <199502040017.QAA11664@estienne.cs.berkeley.edu> from "Justin T. Gibbs" at Feb 3, 95 04:17:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Look, you can diagnose a cache problem: [ ... ] > > Diagnosing a DMA range restriction is similarly easy: [ ... ] > This is not the job of the device driver. I think that many of these types > of problems are detectable. The question is who has the time or interest to > write the code. Providing a mechanism that non-driver code can use to exercise the problem *is* the job of the device driver. For the Ultrastor controllers, barring a method to detect the difference between a 24f and 34f as part of the probe, it's the *only* viable soloution. You're right that this does not mean including the probe code in each driver, but by that same token, it does mean including hooks to allow for block read and write of a single block rather than relying on the VM system to do the right thing. So it's a combination of driver entry points and generalized probe code. Drivers also need an attribute flag to tell whether or not they use DMA and so are succeptable to the problem. This was forcefully brought home by the NCR driver users who had no problems when the probe wasn't as good as it is now, and the driver fell back to polling -- the problem hid itself because of the I/O mechanism used. To hide the problems when they are known means knowinglingly causing non-DMA I/O to be used (the driver need not support that, but allowing such a thing is definitely the job of the device driver, if it is allowed at all), invalidating the cache intentionally before using data resulting from a DMA transfer by a controller (the driver *must* tell us it uses DMA, since like the NCR driver, it may be dual mode), or by explicitly disabling the cache (per page if possible, entirely if not). The Cyrix/TI chip detect and cache disabling code in The Undocumented PC would probably solve 30-40% of the reported problems off the bat, and the source code is in the book. The other cache problems are based on a succeptability code for the driver, or on global succeptability. A driver that can't tell an ISA card from an EISA card *must* either note that it can screw up on DMA above 16M *OR* it must always use bounce buffers. A VLB card is always succeptable to broken cache writeback, unless you can software detect if it is in a master slot or a slave slot. A PCI card is succeptable unless you can tell a bad Saturn/Neptune/Mercury chipset from a good one. An EISA card is succeptable unless you can tell if the board has a HiNT (or other buggy) chipset. Most of this is bus-driver as opposed to card-driver, but the probe is on the basis of causing a detectable failure in a succeptable card driver (with the exception of the Cyrix/TI). A smart driver, on the other hand, means you can penalize only the equipment that is succeptable to the problem instead of all the cards on the machine. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502040040.AA24550>