Return to BSD News archive
Xref: sserve comp.os.386bsd.development:1704 comp.os.linux.development:4813 comp.sys.ibm.pc.hardware.chips:1815 comp.sys.ibm.pc.hardware.storage:2016 comp.periphs:4925 comp.realtime:4438 comp.arch.storage:2297 comp.unix.bsd:13302
Newsgroups: comp.os.386bsd.development,comp.os.linux.development,comp.sys.ibm.pc.hardware.chips,comp.sys.ibm.pc.hardware.storage,comp.periphs,comp.realtime,comp.arch.storage,comp.unix.bsd
Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!usc!elroy.jpl.nasa.gov!decwrl!amd!netcomsv!netcomsv!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: The DMA problem again!
Message-ID: <jmonroyCJxHBH.2x0@netcom.com>
Followup-To: comp.os.386bsd.development,comp.sys.ibm.pc.hardware.chips,comp.periphs
Keywords: DMA overrun RAM refresh FDC problem
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Date: Thu, 20 Jan 1994 12:28:28 GMT
Lines: 128
The DMA problem again!
----------------------
To begin with I have cross-posted this problem quite
widely. The intent is to (perhaps) find a reasonable answer
for all persons involved. Please note -though- that I have
limited the "follow-up". I am well aware that some persons
monitor more than one "newsgroup". :-)
---------------------oOo--------------------
Indeed, the contention that the DRAM refresh (for the
IBM PC-AT) collides with data transfers of DMA dependent devices
(ie. the floppy drive) seems to be in dispute. Truely,
remarks by myself ridiculing the notion that "cosmic rays" and
"alpha particles" being major contributors to this problem
have been less than completely called for. For this, at this
time, I do apologize to any person, or persons, to which my
un-called for remarks may have been placed.
---------------------oOo--------------------
On to the more important issue!
---------------------oOo--------------------
Upon remarking to a friend about problem, his recommendation
was to take the scientific approach. I queried for a better
details. His suggestion was that some tests be constructed so
that conclusive answers to the problem can be made.
This all seems reasonable; so as was suggested by someone
on the '386bsd' newsgroups a "production-level" driver should
be written. I am now formally volunteering to do this work.
I also will gladly accept the comments and suggestions of anyone
concerning this item.
However, in order to determine the best method of design
I am throwing out some ideas for tests that will show evidence
to the DMA problem. (One way or another)
---------------------oOo--------------------
Device Criteria for Test:
-------------------------
1) The RAM refresh is controlled, on many AT-type machines,
by the DMA controller on channel 0 and the (PIT) Timer on
channel 1.
2) Devices like the FDC (floppy drive controller) make
abundant use of this facility and would make good
test platform since most people have them on there
PC type machines.
So to make this clear, I am suggesting the reprogramming of
the DMA, the PIT and the FDC (for test purposes only).
Possible methods for testing:
-----------------------------
1) One of the best and most popular methods for testing
is the burn-in test. (Forgive me if you know this by
another name.) In this type of test a device is
tested repeatedly -without stoppage- for a determined
amount of time. This is good because this type of
test can be repeated often and the results are easily
verifiable by previous tests. However, this method
is not generally great since the DMA problem seems
to be happening at non-determinant times.
2) Another popular method is a rapid-burn test.(Forgive
me again for the possible name unfamiliarity.) In
this method the device (or devices) in-use are run
at an accelerated pace so that the life expectancy
can be determined. This is good because a
determination of typical failures can be made from
this method. What this general says though is that
there is a determinable method for responding to
failures. However, running PC's at high temperatures
tends to cause problems on it's own. So, this may
not be the best method.
3) I don't know a name for this test, so I'll call it
a 'bump and grind' test. (Please excuse the innuendo).
As suggested, the test is a rapid start/stop test.
This method proves a reasonable method since it shows
stress conditions under abnormal circumstances. This
is good because it is abnormality we are looking for.
However, this test does not guarantee that our problem
is in this subset (or domain), so the results are
at best only suggestive.
Analogous examples to previous methods
--------------------------------------
1. Running a car engine in the Monaco 500
at 55 mph for two weeks.
2. Running a car engine in the Indy 500
at 500 mph for two days with an ambient
air temperature of 150 degrees fahrenheit.
3. Beating a hammer on the fender of this
"foo" car.
---------------------oOo--------------------
I have other ideas, but I'd like to hear from you.
Please mail me if you are unsure of anything I've said.
I would be only too happy to make clarifications.
If you understand, please thread to this article, but don't mail me.
___________________________________________________________________________
Jesus Monroy Jr jmonroy@netcom.com
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________
--
Jesus Monroy Jr jmonroy@netcom.com
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________