*BSD News Article 26473


Return to BSD News archive

Xref: sserve comp.os.386bsd.development:1722 comp.sys.ibm.pc.hardware.chips:1943 comp.periphs:4949
Newsgroups: comp.os.386bsd.development,comp.sys.ibm.pc.hardware.chips,comp.periphs
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!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!news.ucdavis.edu!dale.ucdavis.edu!fzshenau
From: fzshenau@dale.ucdavis.edu (Greg Shenaut)
Subject: Re: The DMA problem again!
Message-ID: <CK5AoL.6LL@ucdavis.edu>
Followup-To: comp.os.386bsd.development,comp.sys.ibm.pc.hardware.chips,comp.periphs
Sender: usenet@ucdavis.edu (News Guru)
Organization: University of California, Davis
X-Newsreader: TIN [version 1.2 PL2]
References: <jmonroyCJxHBH.2x0@netcom.com> <1994Jan22.120513.8484@cc.usu.edu> <jmonroyCK4tFo.3Jx@netcom.com>
Date: Mon, 24 Jan 1994 17:45:56 GMT
Lines: 35

Jesus Monroy Jr (jmonroy@netcom.com) wrote:
[stuff deleted]
: 	I am saying the inverse (or is it the converse, anyhow).
: 	I beleive the DMA RAM refresh signal is interfering
: 	with the FDC transfer.

I think that it is at least possible for this to happen.  I remember a
case where we were using an old Mountain tape drive (which uses the FDC
under DMA control) to try to back up a SCSI hard drive which had an
Adaptec 1542 (bus mastering) controller.  The backup failed miserably
when we tried to run the tape software in "overlapped" mode--in this
mode, the disk is read while the results of the previous read are being
written out to the tape; both under DMA control.  We decided that the
problem is due to the fact that the FDC has only a single-byte buffer,
and the data bits must be written out absolutely synchronously.  Thus
if the FDC's DMA transfer is delayed by 8 floppy bit times, the FDC transfer
is munged.  The Adaptec card, even set for the shortest burst length,
would sometimes cause such a delay.

Now the _probability_ of this kind of delay occuring as a result of a
refresh cycle is much lower due to the low frequency of refresh cycles,
but I think that it may be _possible_.  If I were going to try to
demonstrate this, I would try to analyse the timing of the FDC's
DMA request to determine the worst case scenario in terms of the
smallest delay to the completion of the DMA cycle, and then look around
for possible sources of the delay, such as long memory cycles (e.g, to
video memory); higher-priority DMA requests; and refresh cycles.

BTW, I think that channel 0 was used for refresh in XT's, but in AT's,
they freed up channel 0 for use on the bus and added an independent refresh
channel.

Greg
--
Greg Shenaut -- gkshenaut@ucdavis.edu