Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13323 comp.os.linux.development:206 comp.os.mach:3189 comp.os.minix:22577 comp.periphs:4166 comp.unix.bsd:12451 comp.unix.pc-clone.32bit:4106 comp.os.386bsd.development:1108 Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!news!demon!grendel.demon.co.uk!jes 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 From: jes@grendel.demon.co.uk (Jim Segrave) Subject: Re: ^&#%$ DMA Problem Solved ! In-Reply-To: <jmonroyCBw006.DKz@netcom.com> Organization: Segrave Software Services Cc: jmonroy@netcom.com Date: Wed, 18 Aug 1993 20:01:00 +0000 Message-ID: <m0oSthK-0000YBC@grendel.demon.co.uk> Sender: usenet@demon.co.uk Lines: 158 In article <jmonroyCBw006.DKz@netcom.com> you write: > > > ^$#% 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. What evidence? Your interesting arithmetic trying to find harmonics of the DMA refresh rate and floppy transfers? This is hardly evidence, since it took no account of the physical layout of sectors on a floppy. It also played fast and loose with the physical realities of digital logic. >Evidences and Ideas to date: > > 1) Evidence was presented, via a discussion with a > design engineer, that RAM refresh was the problem. He was incorrect > 2) Evidence was presented, that masking the Interrupt > controller (i8259) did not solve the problem. Interrupts have nothing to do with DMA cycles, the only control a processor has over DMA is programming the controllers or using LOCK prefixes. Otherwise a DMA cycle takes place at a level below the CPU. > 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. There are those who are eagerly awaiting some code so that they can evaluate this possibility. > 6) Suggestion was made that possiblely another DMA > device was the culpurit, discounted since the > 386bsd SCSI card was a (SCSI) bus master. Whether the SCSI card is a SCSI master or slave is not the issue. The question is how data gets from the SCSI interface to the system. Most SCSI controllers use DMA and perform the DMA in short - 4 to 8 byte - bursts, simply to prevent timing problems. If the SCSI controller does longer bursts than this, then you will have overruns. I specifically pointed this out to you and you replied: 'NO, the SCSI card is running in interrupt mode, not DMA' Which I took to be a very strange answer - did that mean programmed transfer from the card when an interrupt occured (as is done for IDE and ST506 discs?). If you mean it is a bus matering card, which is more in line with what I expected, it is quite capable of grabbing the bus for an arbitrarily long period. That could cause loss of DMA cycles. > > 7) Evidence was presented that with timing charts that > this was the most likely problem, but was not readily > accepted. I haven't seen anyone post a timing chart, but if they did, it would confirm what I said - there is gobs of time for every byte to be DMAed from the FDC even with refresh running. I told you this, several other people told you this (all of us giving background information as to why this is so), the data books tell you this, the PC tech ref tells you this, a scope on the bus control lines tells you this, the existence of several million PCs using floppys tells you this, the fact that CMS and others sell floppy tape streamers which make their users happy tells you this, what more do you want? > 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. I never suggested that LOCK was being used, I merely included it in a list of ways to create this problem - the heading was: I would have to work hard to cause a DMA overrun. In fact, I said (re LOCK) 'At any rate, I would be surprised if anyone ever did this [used a LOCK prefix on a long instruction] in a single processor environment' >Solution to problem: > > 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. 5 bus clocks at 4.77Mhz - is less than 1.5 usec. So, a refresh request and a floppy DMA request arriving simultaneously would cost you: 5 clocks to get the bus for refresh. A (generous) 5 clocks to do the refresh. 5 clocks to get the bus for the floppy DMA. 5 more clocks to do the DMA. 20 clocks gone - for a total of about 4 uSec. At a 1MBit/sec data rate, this still leaves 4 uSec for PC thumb twiddling. Now bring it into the world of 386/486 m;achines where the bus runs at 6 or 8 Mhz and you've got even more time to burn. Lets summarise: RAM REFRESH WILL NEVER CAUSE LOSS OF DATA FROM THE FLOPPY DISC CONTROLLER or (to paraphrase HJ Lu) RAM REFRESH WILL NEVER CAUSE LOSS OF DATA FROM THE FLOPPY DISC CONTROLLER RAM REFRESH WILL NEVER CAUSE LOSS OF DATA FROM THE FLOPPY DISC CONTROLLER RAM REFRESH WILL NEVER CAUSE LOSS OF DATA FROM THE FLOPPY DISC CONTROLLER > 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." All this is very nice, but PC's use NEC765 floppy controllers, not the Intel chip. I have never encountered any PC which had a 82072 or its ilk FDC, they always use 765's or derivitaves. These chips don't have FIFOs. If they did have FIFOs they would be even less likely to suffer from overrun problems, since they could afford to defer transfers for more than one byte time. The FIFOs are there for non-DMA systems to allow programmed I/O to be used to read and write to the floppy. At any rate, it is all irrelevant to existing PC hardware. -- Jim Segrave (Segrave Software Services jes@grendel.demon.co.uk)