Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!sgiblab!swrinde!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!jmonroy From: jmonroy@netcom.com (Jesus Monroy Jr) Subject: Re: [FreeBSD 1.0R] DMA Problems? Message-ID: <jmonroyCIvwpv.8F3@netcom.com> Organization: NETCOM On-line Communication Services (408 241-9760 guest) X-Newsreader: TIN [version 1.2 PL1] References: <jmonroyCIHJA2.oy@netcom.com> <2fl24q$jn2@u.cc.utah.edu> <jmonroyCIo4yD.1G5@netcom.com> <2fnapb$6eb@u.cc.utah.edu> Date: Fri, 31 Dec 1993 05:32:19 GMT Lines: 134 A Wizard of Earth C (terry@cs.weber.edu) wrote: : 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? : Yes, the question states my <4am> response quite clearly. : 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? : I must report that I did not design, engineer or approve this hardware design. I am only reporting the facts as I know them. The actual electronics, and how they work was not part of my computer studies, nor was is it required for programming the IBM PC/AT. The answer to your question is RTFData Guide. :-) (This is a freindly RTF*.) ;-) : If you can do this, what *exactly* is the problem with the FDC? : I think I've stated the problems with DMA overruns quite clearly. Would you like a copy of my notes? <I don't want to bore the net with prior knowledge> :-) : Why not : just reprogram the i8237 giving it higher priority so it can also *PREEMPT* : the SCSI operation. End of problem. : 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. : >: > 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. : I don't know if I can say that I truthfully can say I have an answer for either "a" or "b". But a redesign of the RTC system would help identify the problem *and* solution more clearly. : 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). : My answer is "I don't know if DRAM refresh skipping can solve the problem. I have not considered it seriously." : 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". : 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. -- Jesus Monroy Jr jmonroy@netcom.com Zebra Research /386BSD/device-drivers /fd /qic /clock /documentation ___________________________________________________________________________