Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!sol.ctr.columbia.edu!news.kei.com!ub!csn!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: 27 Dec 1993 18:50:19 GMT Organization: Weber State University, Ogden, UT Lines: 85 Message-ID: <2fnapb$6eb@u.cc.utah.edu> References: <jmonroyCIHJA2.oy@netcom.com> <2fl24q$jn2@u.cc.utah.edu> <jmonroyCIo4yD.1G5@netcom.com> NNTP-Posting-Host: cs.weber.edu In article <jmonroyCIo4yD.1G5@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes: > This statement is incorrect. On the IBM PC/AT/XT arch. The > ram refresh has priority because the DMA chip, the i8237, > by design gives priority (if programmed) to the lowest DMA > channel request, channel 0. The programming information > for the i8237 is available. If you don't have a copy of > it I will be happy to send you a photo copy, please let > me know. I take it that this means it is your impression that a DMA request on channel 0 will *PREEMPT* an existing DMA operation on another channel? I would like to undestand how you reach this conclusion. Tell me: How do you notify the AHA1542 that it should discontinue its DMA operation once it has gotten bus grant so that you can do your "DMA channel 0 based" refresh? If you can do this, what *exactly* is the problem with the FDC? Why not just reprogram the i8237 giving it higher priority so it can also *PREEMPT* the SCSI operation. End of problem. >: > my information says that you can skip a few "RAM refresh" >: > cycles... what are you saying? Terry>: You can. Tell me: how do you allow "skipping", but deterministically Terry>: sufficient skipping for the potential well to discharge to the point Terry>: that the memory contents are no longer reliable? There is no hardware Terry>: "skip count"... DRAM refresh is not a realtime process which will Terry>: interrupt other things on your motherboard to safeguard your memory Terry>: contents. > I beleive you asked a question and answer it yourself. > If I am correct and you want me to say yes to the > answer to your questions, I do no understand you answer. > > If you answer is "there is not hardware 'skip count'." > You are correct. To my knowledge there is no hardware > skip count for any DRAM refresh hardware; not to date anyway. > > If your statement includes the premise that DRAM refresh > is *not* a realtime process which *will* interrupt other > "things" to safeguard your memory, this is incorrect - > by the design for IBM PC/AT/XT (et. all). 1) My question stands: the only potential way I could see to make *certain* you didn't skip too many refreshes was to count the number of skips and *not* allow too many of them to occur. There is, of course, a presumption that it is possible to determine exactly what "too many" means. I am open to suggestions *other*than*a*skip*count* as to how *you* propose to solve the problems of: a) How many skips is "too many". b) How do you prevent "too many" skips from *ever* occuring. 2) My statement *did* include the premise that DRAM refresh is not handled realtime. This does not effect the validity of the questions; they still need answers. If your answer is "it is a realtime process" and thus "too many skips can never occur because one skip can never occur because it is a real time process", then I will point you at your own code, which can programatically skip DRAM refresh (making it non-realtime). Terry>: How many you can skip is dependent on the chip and the bus rate and Terry>: the on-time for the refresh... in other words, how deep the potential Terry>: well is, how long it is charged on initial write, and how long it is Terry>: charged on each refresh. And there is *no* way to probe this from Terry>: software. > I disagree. In the PC world there are plenty of PD and > shareware programs that reprogram the DMA facility to accomplish > just what you stated is not possible. 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". Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.