Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Newsgroups: comp.os.386bsd.development Subject: Re: [FreeBSD 1.0R] DMA Problems? Date: 1 Jan 1994 09:53:34 GMT Organization: Weber State University, Ogden, UT Lines: 60 Message-ID: <2g3h6u$eos@u.cc.utah.edu> References: <jmonroyCIo4yD.1G5@netcom.com> <2fnapb$6eb@u.cc.utah.edu> <jmonroyCIvwpv.8F3@netcom.com> NNTP-Posting-Host: cs.weber.edu In article <jmonroyCIvwpv.8F3@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes: > This is possible, but the timing inconsitency might crash the > system. To make it work correctly it would require a rewrite > of the RTC (Real Time Control) System. I beleive you > have a copy of my report on this, so further details are > available there. I agree that the clock code needs rewritten -- but mostly for TQE style event processing and for select-in-kernel-without-buzzloop and finally to allow future use as a realtime box (with more changes). The sum of the QIC-40/80 requirements are there to avoid buzz-looping in the driver ad taking the system to its knees. Admirable goals, but not strictly a requirement for a driver -- as has been proven by a Linux Driver, a BSD driver, and Vadim Atinov's code for BSDi (and the SCO code and...). I don't think a driver could be reasonably used to back up a drive over the network, and it is somewhat questionable on slow (ie: not as fast as mine) machines with most (again, not mine) fixed disk controllers. Spending 60% of the machine buzzing or doing seeks to keep the tape in a usable place but not streaming, are simply not commercial quality in my opinion (Vadim's driver is the best one of the lot, and it could still benefit in some small places -- he was real tricky). >: Let me get this straight. You can tell me how many DRAM refreshes it is >: safe to skip for a given piece of hardware? This is the only statement >: I have made that implies I believe something to be impossible: "And there >: is *no* way to probe this from software". > To clarify the issue: DMA DRAM refresh skipping would be a > bad term to use. What happens is the timer for channel 0, > the DRAM refresh timer, is reprogrammed so that there are > less refreshes per second (ie. 2000 new vs. 3000 old refreshes > per second). The idea is to have more system *resource time* > to do other tasks. > > It is possible, via software, to reprogram the refresh cycle. > My example program does this. The results are had when the > system crashes. That is, to make this a software *probe* > the program would (if it existed for *BSD) slowly turn down > the timer till the system crashed. At this point, some > test could readily determine the *consistency* of ths system. > > I hope this is clear. It is, but I still don't agree with it. The problem that I see is that the DRAM contents need to be kept above fail level -- where the 1 may be seen to have flipped over to a 0. But any kind of probe can't determine that, because you may get something that *seems* to work, but of a period of time will converge to the fail level. This is because the write will result in a high capacitive charge, and adding charge incrementally must still exceed the drain rate -- if it does not, and only does not barely, then over a long time, the memory will seem to fail -- unless you propose to wait 5 days for the probe to complete. Regards, Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.