Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!paladin.american.edu!europa.eng.gtefsd.com!uunet!Germany.EU.net!netmbx.de!zrz.TU-Berlin.DE!zib-berlin.de!irz401!uriah!not-for-mail
From: j@uriah.sax.de (J Wunsch)
Newsgroups: comp.os.386bsd.development
Subject: Re: [FreeBSD 1.0R] DMA Problems?
Date: 23 Dec 1993 12:37:28 +0100
Organization: Private U**X site; member IN e.V.
Lines: 43
Message-ID: <2fbvtoINNk71@bonnie.sax.de>
References: <CHCErs.G5w@genesis.nred.ma.us> <2dj25i$1ga@u.cc.utah.edu> <2encotINN3sq@bonnie.sax.de> <2eqjt7$dqm@u.cc.utah.edu> <CI6291.HBA@genesis.nred.ma.us>
NNTP-Posting-Host: bonnie.sax.de
steve2@genesis.nred.ma.us writes:
>I originally asked the question so hopefully I can clarify things a bit.
>>... BECAUSE the floppy does
>>*not* _ALSO_ use DMA, ...
[This statement is totally WRONG. It's just the opposite: only the floppy
uses DMA by default. The dRAM refresh in an AT is no more done by a DMA
channel, and the typical AT hard disk uses programmed IO by the CPU. The
only one else using DMA (as bus-mastered DMA) are SCSI host adaptors.]
>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
Hmm, strange. Where is the difference between both directions?
>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.
[my suspicion about concurrent hard disk activity as the reason deleted]
>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
Do i understand you right: you can reproduce the problem even with _only_
heavy CPU load (no other heavy disk IO e.g. by a compiler)?
>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.
No, though video could cause troubles (the VGA delays the bus access to
the frame buffer until some video blanking happens), this problem also
occurs if no additional video output is done.
--
in real life: J"org Wunsch | ) o o | primary: joerg_wunsch@tcd-dresden.de
above 1.8 MHz: DL 8 DTL | ) | | private: joerg_wunsch@uriah.sax.de
| . * ) == |
``An elephant is a mouse with an operating system.''