Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!nigel.msen.com!sdd.hp.com!usc!news.service.uci.edu!network.ucsd.edu!network!bill
From: bill@kepler.ucsd.edu (Bill Reynolds)
Newsgroups: comp.unix.bsd
Subject: ISA/DMA in 386BSD
Date: 24 Oct 92 00:56:33
Organization: Institute for Nonlinear Science, UCSD
Lines: 71
Distribution: world
Message-ID: <BILL.92Oct24005633@kepler.ucsd.edu>
NNTP-Posting-Host: kepler.ucsd.edu
A hot topic recently in the pc-hardware/pc-unix newsgroups has been
the relative merits of EISA vs. ISA busses. It has been pointed out
that a shortcoming of ISA is that, due to its limited addressing
capability, DMA under ISA needs some special black magic from the
operating system in order to work.
My first question is regarding the nature of the problem. I'm not a
unix/cs guru. My understanding of exactly what all these terms mean is
sketchy, so I'd appreciate some clarification. Currently, my
understanding is the following: There is a facility whereby a device
can directly access the system memory, without having to tie up the
cpu (DMA). Unfortunately, if the memory that the device wants to get
at is above some limit (16M), the (24 bit ISA) address overflows, and
there is hell to pay. So if a device wants to perform DMA, the
operating system must first copy the relevant region of memory
someplace below the ISA ceiling, whereupon the DMA can proceed
normally. So, on to the first question: Is this right? If so, how much
of a hit is the memory copy/DMA process over a straight DMA? How great
are the advantages of a device (e.g. a disk controller) that does DMA?
Enough to justify buying an EISA system, which does not have this
memory addressing limit (as I understand it)? Do the other advantages
of EISA justify the expense?
The next question is an extension of the previous one - if a device is
sitting on a VL bus, which is (as I understand) 32 bits wide, will it
be subject to the same limitation on DMA? I just read a post that says
that while a local bus is busy, the CPU will wait, leading to a big
lose for a multitasking OS like unix. Is this true? If so, how bad
will it impact overall performance?
My next question regards the following code fragment from
/usr/src/sys.386bsd/i386/isa/isa.c, which seems to perform the copy
described above.
if (isa_dmarangecheck(addr, nbytes)) {
if (dma_bounce[chan] == 0)
dma_bounce[chan] =
/*(caddr_t)malloc(MAXDMASZ, M_TEMP
, M_WAITOK);*/
(caddr_t) isaphysmem + NBPG*chan;
bounced[chan] = 1;
newaddr = dma_bounce[chan];
*(int *) newaddr = 0; /* XXX */
/* copy bounce buffer on write */
if (!(flags & B_READ))
bcopy(addr, newaddr, nbytes);
addr = newaddr;
}
This code seems to do exactly what was just described: it checks to
see if the requested piece of memory is reachable, if it is not, it
decides on a new address to which it will bcopy the data to. However,
the line marked /* XXX */ then sets this adress to 0. My impression is
that this code is incomplete. This leads to my next question: What is
going on here? If it's broken, what needs to be done to fix it? Is it
a lot of work? If possible, how much work would be involved to extend
this to a VL-Bus?
Sorry for all the questions, but from reading stuff on the net, it
seems that I'm not the only one confused about the limitations (and
terminology) of the current pc technology, so if I get some good
explanations, I'll be sure to summarize. Thanks for the help.
--
_______________________________________________________________________
Bill Reynolds | **** HE'S LYING ****
bill@kepler.ucsd.edu |