Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13317 comp.os.linux.development:117 comp.os.mach:3180 comp.os.minix:22565 comp.periphs:4138 comp.unix.bsd:12429 comp.unix.pc-clone.32bit:4084 comp.os.386bsd.development:1079
Newsgroups: 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
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!wupost!csus.edu!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: even more on that DMA problem
Message-ID: <jmonroyCBw0n4.EID@netcom.com>
Keywords: DMA i8273 overrun fdc timing
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Date: Tue, 17 Aug 1993 05:01:52 GMT
Lines: 103
It doesn't seem like this posted the first time.
So here it is:
=======================================================================
^$#% DMA Problem Solved!!
-------------------------
After much disccussion (arguement) the DMA problem,
today 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
for this. The causes is that the DACK
(DMA Acknowledge) to falls 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:
1) Evidence was presented, via a discussion with a
design engineer, that RAM refresh was the problem.
2) Evidence was presented, that masking the Interrupt
controller (i8259) did not solve the problem.
3) In the same article, evidence that masking off
the DMA controller (i8237) did not help.
4) Reprograming the DMA controller did not help.
5) Suggestions were made that the device driver was
written in error.
6) Suggestion was made that possiblely another DMA
device was the culpurit, discounted since the
386bsd SCSI card was a (SCSI) bus master.
7) Evidence was presented that with timing charts that
this was the most likely problem, but was not readily
accepted.
8) Finally, not presented, but e-mailed to me an
inspiration that maybe the compiler was using
the "LOCK" nuemonic for variables with the modifer
"volatile". This was discounted because of the
irrattic method that GNU C++ uses the "LOCK"
mechanism.
Solution to problem:
Irregular comments by many have spurred these
ideas and even though some things may have not
been done in a wholely profession nature,
none the less, the remarks were taken as positive,
when positive.
LAST BACK FLAME:
Have a nice day.
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
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________