Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!jmonroy From: jmonroy@netcom.com (Jesus Monroy Jr) Subject: Re: [FreeBSD 1.0R] DMA Problems? Message-ID: <jmonroyCI6HID.HsA@netcom.com> Organization: NETCOM On-line Communication Services (408 241-9760 guest) X-Newsreader: TIN [version 1.1 PL8] References: <2encotINN3sq@bonnie.sax.de> Date: Fri, 17 Dec 1993 12:03:49 GMT Lines: 58 J Wunsch (j@uriah.sax.de) wrote: : In <2dj25i$1ga@u.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: : >[ ... DMA problems with FDC ... ] : >It is probably your cache. ... : >... device initiated DMA has the potential : >to update memory without updating cache (on reads) or write data that is : >valid in cache but not in memory (unless your cache is write through) on : >writes. : Umm, Terry, i think you failed here. : The FDC does not do any ``device initiated DMA'' in this sense. It's simply : using the DMA chipset feature. This *should* not conflict with cache usage - : or the chipset design is broken. [We do not speak about SCSI host adaptors : that do bus-master DMA.] : In fact, i'm also experiencing lotta DMA overruns when attempting to do : some floppy IO while some heavy compile job is running. This is in a box : with an Adaptec SCSI, and i didn't track it down whether it's the CPU : load that causes the trouble (would really look strange to me), or if : it's the heavy disk IO that happens while compiling. : Assuming it's the latter, so it could be some problem with the host adaptor : DMA cycles - does the adaptec really care for other DMA requests floating : around on the bus while it is considering to take over the bus? : About two (or three) months ago, I started questions about this DMA problems. (I still have my notes if interested) The basic problem is that the FDC (FLoppy Drive Controller) chip was never mant for the type of heavy work that you described. There are a few problems 1) The DRAM refresh has priority over any FDC transfer. I think (don't quote me) the refresh is about 3000 times per second. 2) The FDC has no on-board buffering (no FIFO or RAM). 3) The maximum allowed latency time between any two bytes in a DMA transfer is shorter than the RAM refresh cycle. 4) (more unrelated stuff... e-mail if interested).... : As a workaround, Serge Vakulenko proposed to simply ignore the DMA overrun : error and retry the transfer until it succeeds (or some other error occurs). : Yes, this is the standard method use by most FDC drivers I have encountered. The alternate is to by a new FDC chip, like the Intel 82077a. I have not found any adapters yet that use this chip, but if you call Intel they will send you a list of people that will sell you a new chip. -- Jesus Monroy Jr jmonroy@netcom.com Zebra Research /386BSD/device-drivers /fd /qic /clock /documentation ___________________________________________________________________________