Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!nic.hookup.net!swrinde!cs.utexas.edu!uunet!news.centerline.com!noc.near.net!ceylon!genesis!steve2 From: steve2@genesis.nred.ma.us Subject: Re: [FreeBSD 1.0R] DMA Problems? Message-ID: <CI6291.HBA@genesis.nred.ma.us> Organization: Genesis Public Access Unix +1 508 664 0149 References: <CHCErs.G5w@genesis.nred.ma.us> <2dj25i$1ga@u.cc.utah.edu> <2encotINN3sq@bonnie.sax.de> <2eqjt7$dqm@u.cc.utah.edu> Date: Fri, 17 Dec 1993 06:34:09 GMT Lines: 63 I originally asked the question so hopefully I can clarify things a bit. >Geeze... this is a real old discussion; let's see if I can remember... > >He was taking about DMA problems trashing his floppy I/O; without a more >complete discussion of exactly what was happening (which if it could be >done meant that the question wouldn't have needed to be asked 8-)), the >only thing I could see was the data being read off the disk using DMA >and then written to the floppy not using DMA. BECAUSE the floppy does >*not* _ALSO_ use DMA, then there could be a cache related problem. I am doing FDC I/O using DMA to kernel space. DMA reads (device writing memory) were working just fine, but DMA writes would fail with DMA overruns if I did something CPU intensive. The transfer would die partway through. The transfer is being done below the 16Mb mark, and slowing the bus speed down seems to make the problem more frequent. I changed my driver to restart the entire transfer if it noticed a DMA overrun. This works but is annoying because there are many retries if the system is busy. I tried playing with the caching a bit. Because I have a 486, I disabled caching by modifying pmap_enter to OR in 0x18 on the pte as opposed to entirely disabling caching via setup. This appears to cure the problem but response time was poor. After that I wrote a small function to only disable caching on my DMA buffer pages, but the problem returned. >This could probably be ignored if it were program generated data >going to the floppy... but if it wre, for instance, a tar of a >directory or a cp of a file, then the DMA into the machine from the >disk could be what is screwing up -- and that because of cache problems. >>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. That doesn't appear to be the case. The buffer is pre-loaded for the write, and there doesn't have to be any other disk transfers going on for the problem to happen. This is why I'm still a little baffled. Only three things need to go on for an overrun: an FDC DMA write (device read), another busy process running with the transfer, and possibly video I/O. In fact, video is my next suspect. >>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). > >Yup. The DMA timeout falls into the soft error classification; standard >procedure is retry until *contiguous* fail count hits some max, after >which it is treated as a hard error. This is the method I've gone with for the time being. I'm not too happy about it, since it's very possible the overrun conditions will often cause a failure. In case I didn't mention, my controller is an UltraStor 24F, not an Adaptec. My system is a 486DX2/50 EISA, with 8mb of RAM. I'm still open for suggestions if anyone has any more. Thanks, - Steve steve2@genesis.nred.ma.us