Return to BSD News archive
Xref: sserve comp.os.386bsd.development:1727 comp.periphs:4953
Newsgroups: comp.os.386bsd.development,comp.periphs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!decwrl!decwrl!netcomsv!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: Restart of discussion on the DMA problem.
Message-ID: <jmonroyCK8tAL.4GD@netcom.com>
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Date: Wed, 26 Jan 1994 15:20:45 GMT
Lines: 194
mail jarle@drue.idt.unit.no
Re: Subject: Re: The DMA problem again!
Restart of Discussion of the DMA problem
----------------------------------------
For the purpose of
1) discussion and
2) to remit to the truth and
3) so that we can get on the real issue (DMA overrun)
I will admit that statements made by me(myself and I) have been
misleading (in some cases out right incorrect).
I will admit that the DRAM (not SRAM, not VRAM) is refreshed
via timer 1 with the Intel 8254 PIT (Programmable Interrupt Timer).
I will admit that I (on occasion) have enumerated DMA channel 0
as being an element in the DRAM refresh; this is not correct.
Correctly, DMA channel 0 is not directly involved in the DRAM refresh
on the IBM PC-AT (or 100% compatibles).
I will admit that my statements have in some context been
misleading (technically - not entirely correct or kosher).
I am also willing to admit that possibly the DRAM refresh
is not the problem in the DMA overrun problem.
Once again so that the real issue, DMA over/underrun
may be discussed I admit to the above statements.
=========================================================================
>> Date: 25 Jan 94 00:51:38
>>
>> Oh boy, doesn't anyone else find this thread tiresome? Now it gets worse!
>>
>> Well, since you seem to insist, let's read some schematics then, shall we?.
>>
>> What does all this mean then?
>> For one, the DMA channels are not used for refreshing!
>> (Do you read me Mr. Monroy?)
>>
Correct. The DMA channel 0 (or any other channel) is not used
in the DRAM refresh. This point was mentioned early on and
I had forgotten it, so my latest statements have been
incorrect (on this regard).
>> The refresh cycles are controlled by the system timer.
>>
Yes, from all my information this is correct. As a matter
of fact I wrote a program:
i8254.sha on etext.archive.umich.edu:/pub/Zines/QIC-News
that shuts down the timer, thereby proving your statement
and mine on this point.
>> Second the refresh cycles can *not* preempt an ongoing DMA cycle.
>>
I will disagree with the wording only. I beleive your
context to be correct. That is, once a DMA cycle starts
(the HRQ (Hold ReQuest) is answered) no other process can
- interrupt, stop or intervine - with the Data Transfer.
However, a process can - interrupt, stop or intervine -
between DMA byte-to-byte lapse time. That is, the DMA
cycle (in Single mode or Demand mode) can have activities
in between each byte transfered. (I hope this is clear.)
>> It can, however, delay a DMA request for at most 5 sysclk cycles
>> (which @ 8Mhz should be approximately 625 ns), which in itself is not
>> enough to disrupt FDC DMA transfers.
>>
I don't have the timing charts in electronic format, but
I am willing to type them in.
>> End of IBM AT discussion.
>>
>>
=======================================================================
Restart discussion of IBM AT
----------------------------
It is my own fault for being dragged into the
sillyness of this entire discussion. Upon reflection
I would like to thank Jarle Greipsland for is patience.
Indeed his statements are correct!
Further, I had at one time made a recommondation
for this problem. It was dated: Tues 08-17-1993;
a shortened context follows.
I still plan to follow-up this problem with the
DMA (over/under)run. I would still like some suggestions
as to making a determination of the best way to deal with
this problem (wheter it is non-determinate or not).
Plainly, I can show that the FDC has an overrun
problem, and the the problem seems to be somewhat
cyclical (this is a bad word; maybe repeatable or
recurring) in nature.
The Goal is to have a more stable, more reliable, more
dependable system. I beleive if some you put aside the
personal inuendos that this problem might be solved.
Least of all we will have a better system (OS).
For the present I am still recommending the Intel 87087a/b/c
(formerly the i87072) over the standard FDC chip for this
DMA problem.
COMMENTS/DISCUSSION/CROSS-ISSUES???
========================================================================
Released to: comp.os.os2.programmer comp.os.linux.development
comp.os.mach comp.os.minix comp.periphs comp.unix.bsd
comp.unix.pc-clone.32bit comp.os.386bsd.development
Released as: %$#@$ DMA Problem Solved
Released: 22:01:35 Tue 08-17-1993
^$#% DMA Problem Solved!!
-------------------------
After much disccussion (arguement) the DMA problem,
today we may have a conclusion. This DMA problem was a major
stumbling block for 386bsd release 0.0. I won't go into
details on this now, I will write an article on this and give
all the details.
Basic problem: Basicly, (we think) the RAM refresh is colliding
with the FDC DREQ(DMA request). Actually any fast
DMA device can have initate this problem, it just
happens that the RAM refresh is a common demoninator.
The cause is that the DACK (DMA Acknowledge) to falls
too late. Much dissucssion ensued on this suggestion
with many people insisting that it was not likely or
possible. Today I have the conclusive evidence that
this is the most *likely* problem.
Evidences and Ideas to date:
:: [deleted irrelevant material] ::
Solution to problem:
:: [deleted irrelevant material] ::
From the 1988:
"Intel Microprocessor and Peripheral Handbook,
Volume 2"
Application Note: AP-289
"Designing with the 82072 CHMOS Single-Chip
Floppy Disk Controller"
in
Chapter 3, Section 3.3
"Setting the FIFO Threshold"
"The transaction involved in bus acquisition and
release imply overhead resulting in losing system
clocks due to signal propagation delays and
arbitration time requirements. For many short DMA
bursts, up to 5 clocks are lost due to this switching.
On the other hand, long burst transfers imply that
other masters will experience long delays in bus
acquisition. An optimal FIFO thresold must be
selected that improves system performance and, at the
same time, ensures that OVERRUN and UNDERRUN errors
are avoided."
The i87072, FDC, is equiped with a 16 byte FIFO.
--
Jesus Monroy Jr jmonroy@netcom.com
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________