Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!zip.eecs.umich.edu!caen!uwm.edu!cs.utexas.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!mcrware!adam From: adam@microware.com (Adam Goldberg) Subject: Re: The ###^%$ DMA problem from the EISA side. Message-ID: <1994Jan16.170028.14868@microware.com> Keywords: DMA EISA ISA overrun FDC QIC-40/80 Sender: news@microware.com Nntp-Posting-Host: ren Organization: Microware Systems Corp., Des Moines, Iowa References: <jmonroyCJo4rD.Gs1@netcom.com> Date: Sun, 16 Jan 1994 17:00:28 GMT Lines: 46 In <jmonroyCJo4rD.Gs1@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes: >In ISA systems, the system needs to have refresh cycles generated about every >15 microseconds. This is a shared responcibility between the system's >Interval Timer 1, Counter 1 and and 16 bit ISA bus mastering devices. >Any 16 bit bus mastering device is responcible for generating the REFRESH* >signal every 15 microseconds if they are in control of the bus for longer >than 15 usec. Sadly, not all such devices followed the ISA spec. in this >regards. > >[...] >Again, speculating on what the root cause of these thread's debate is, it >sounds as if a data corruption problem caused by DRAM refresh failure may >be occuring due to an improperly implemented ISA board not generating the >REFRESH* signal. I would speculate that perhaps this wasn't noticed on DOS >because DMA was not used to communicate with the board, programmed I/O was. Or rather, even if DMA was used to communicate with the card, there was only one bus-mastering card in use at one time. See below. >So many of these improperly implemented ISA boards exist that the authors of >the EISA specifications worked hard to "work around" this problem so that such >boards would be more likely to work in an EISA system they they did in an ISA >system. In a system I have worked on (which is not Linux-related), I have an 154x controller reading data and an MPEG-decoder board receiving the data, both using bus-master DMA. The problems involving DRAM refresh went something like this: the Adaptec card was sending data on one DMA channel, and the MPEG board was reading data on another, and neither was on the bus for >15us. Unfortunately, both cards active at one time would (under some circumstances) ping-pong between the two, starving DRAM refresh. Fortunately, the Adaptec cards have configurable BUS-ON & BUS-OFF timings. Decreasing the BUS-ON from the default 11us to 6us resolved this problem. Amazing what 5us can do sometimes. -- Adam G. adamg@microware.com, or ...!uunet!mcrware!adamg The above is not to be construed in any way as the official or unofficial statements of Microware, or any Microware employees.