Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13320 comp.os.linux.development:168 comp.os.mach:3185 comp.os.minix:22571 comp.periphs:4153 comp.unix.bsd:12438 comp.unix.pc-clone.32bit:4093 comp.os.386bsd.development:1098 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!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uunet!pipex!ibmpcug!ibmpcug!jshark!joe From: joe@jshark.inet-uk.co.uk (Joe Sharkey) Subject: Re: even more on that DMA problem Organization: Individual Network (UK) Date: Tue, 17 Aug 1993 23:01:52 GMT Message-ID: <CBxEn5.MJp@jshark.inet-uk.co.uk> Followup-To: poster Keywords: DMA i8273 overrun fdc timing References: <jmonroyCBw0n4.EID@netcom.com> Lines: 98 In article <jmonroyCBw0n4.EID@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes: > ^$#% DMA Problem Solved!! > ------------------------- What DMA problem? > > After much disccussion (arguement) the DMA problem, > today may have a conclusion. >Basic problem: Basicly, (we think) the RAM refresh is colliding > with the FDC DREQ(DMA request). Actually any fast .... I now introduce "hidden refresh", performed by the motherboard itself and invisible to add-on cards. Does this make things better or worse ? > 6) Suggestion was made that possiblely another DMA > device was the culpurit, discounted since the > 386bsd SCSI card was a (SCSI) bus master. From the quote below, you should *not* have ignored this ;) > 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. Doesn't the 386 ignore LOCK one "long" instructions? [[ Actually, doesn't it only honour it on a limited number of instructions? ]] >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. The whole thing has been a mess. You started by implying that interrupt-driven systems using DMA on PC-type hardware will relaibly(!) ``soon''. It works - has done for years: Microport V/AT in 1986 and since. > LAST BACK FLAME: > Have a nice day. Californians. ;) > From the 1988: > "Intel Microprocessor and Peripheral Handbook, > Volume 2" Hey, you bought a Data Book! > Application Note: AP-289 > "Designing with the 82072 CHMOS Single-Chip > Floppy Disk Controller" > > "The transaction involved in bus acquisition and > release imply overhead resulting in losing system > clocks due to signal propagation delays and > arbitration time requirements. This will be about MultiBus systems, Intel books always are. > 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. Oops! This just proves that your scenario is just plain *wrong* :-( If a DMA operation takes 5 cycles (800nsec @ 6MHz, with about 12usec/byte from the floppy drive) - a 16 byte FIFO would allow about 200usec delay before the FDC DMA logic timed out. Now, what were you saying about DMA? ``Have a really meaningful day.'' >Jesus Monroy Jr joe. -- Joe Sharkey joe@jshark.inet-uk.co.uk ...!uunet!ibmpcug!jshark!joe 150 Hatfield Rd, St Albans, Herts AL1 4JA, UK Got a real domain name (+44) 727 838662 Mail/News Feeds (v32/v32bis): info@inet-uk.co.uk