Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!news.kei.com!sol.ctr.columbia.edu!math.ohio-state.edu!caen!usenet.coe.montana.edu!decwrl!netcomsv!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: Re: [FreeBSD 1.0R] DMA Problems?
Message-ID: <jmonroyCJ5JMy.EnM@netcom.com>
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <2fl24q$jn2@u.cc.utah.edu> <JTW.94Jan3234318@pmws.lcs.mit.edu> <jmonroyCJ3u56.1us@netcom.com> <2gd27p$dc6@u.cc.utah.edu>
Date: Wed, 5 Jan 1994 10:25:45 GMT
Lines: 111
mail terry@cs.weber.edu
Subject: Re: [FreeBSD 1.0R] DMA Problems?
>> Date: 5 Jan 1994 00:39:21 GMT
>> In article <jmonroyCJ3u56.1us@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes:
>> >John Wroclawski (jtw@lcs.mit.edu) wrote:
>>
>> :: [deleted stuff] ::
>>
>> > I'm sorry for this reply... but
>> >
>> > Sagitarius (sp?) won't align with the moon for at least
>> > four days.... Can I give you an answer then?
>> >
>> > What is this "cosmic ray" stuff?
>> > Somebody please tell me if I should take this seriously?
>>
>> Yes, you should take it very seriously. Here, John is demonstrating a
>> better knowledge of solid state physics than most coders who dabble in
>> hardware drivers.
>>
So what... He's right... what does this have to do with
1) DMA Overruns
2) testing for RAM bits dropout from lack of refresh.
3) The twelve asian women I mentioned.
>> Cosmic Rays are high energy particles from outer space -- you may have
>>
>> :: [stuff deleted I did not even read... sorry .. Terry] ::
>>
>> beyond the guaranteed minimal operational parameters.
>>
>> John knows what he is talking about with regard to noise sources, even
>> if you have never had to consider the issues.
>>
I will say, "John may be the expert but what does this have
to do with the problem!"
>> This type of "probing" was *exactly* what I felt could not be done
>> reliably as well -- and why I believe screwing with refresh has nothing
>> to do with your bus-on/bus-off problems getting resolved.
>>
Bus-on/Bus-off may have nothing to do with RAM refresh.
I never said that it did.
>> You may not respect the EE's who build the things, but you have to
>> respect the physics behind it, or you will constantly run into one
>> "mysterious" problem after another.
>>
Physics?
Let's get one thing clear... and you can take this to the bank.
--------------------------oOo------------------------------
"Electricity (sp?) is the theory, Gravity is the Law."
-retired Mainframe Software Engingeer
=======================================================================
mail gordon@sneaky.lonestar.org
Subject: Re: [FreeBSD 1.0R] DMA Problems?
>> Date: Tue, 4 Jan 1994 12:17:26 GMT
>> > 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
>>
>> Timer 0 is the DRAM refresh timer? Not on my system.
>> (Timer 0 = timer interrupt, Timer 1 = refresh, Timer 2 = speaker)
>>
You are correct.... My notes indicated this, but
in the hast to write this reply I errored.
Timer channel 1 is the correct timer... thank you Gordon.
>> > 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
>>
>> The proper way to do this is to test this while operating the environmental
>> controls to extremes of temperature and power supply voltages, and using
>> lots of patterns in RAM. Oh, your system doesn't have controls like that?
>> This probe routine would likely take an hour to run an adequate test even
>> at ONE set of temperatures and power supply voltages. That's a long time
>> to boot. Sure, you can probably do it a lot faster if you have expensive
>> analog measuring equipment attached to the system, but you don't. Also,
>> remember that refresh failure doesn't guarantee a crash.
>>
>> Even if you test it properly, when it becomes known that your OS fiddles
>> with refresh this way, you can be sure that the reaction when you come to
>> a DRAM manufacturer and say "bad RAM", they'll start laughing.
>>
I agree with your comments, Gordon.
I think you made the point I was aluding to, but did not
want to say... I just want some people to do some thinking
first. (There I said it.)
--
Jesus Monroy Jr jmonroy@netcom.com
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________