Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA7783 ; Tue, 26 Jan 93 07:00:16 EST
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386BSD] Still trying to install...
Message-ID: <1993Jan24.222618.28117@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1993Jan21.092014.15598@Princeton.EDU> <1993Jan24.012227.13456@fcom.cc.utah.edu> <AOKI.93Jan23202330@risk.Stanford.EDU>
Date: Sun, 24 Jan 93 22:26:18 GMT
Lines: 49
In article <AOKI.93Jan23202330@risk.Stanford.EDU> aoki@risk.stanford.edu (ikuro aoki) writes:
>
> >>the cache overlays an area used for a disk I/O.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>I would like to know where is the area.
It depends on whether you are doing real DMA, or whether you are doing "DMA"
by virtue of a copy-buffer after an interrupt. Basically, this boils down
to "Does the controller copy the buffer from the controller to main memory,
or does the main CPU do the copy?".
In the case of real DMA, this is any address in the lower 16M of memory.
It is possible (but not currently done) to restrict the region used for
the DMA by placing the copy buffers at a well known address. This would
probably provide for "bounce buffers" to copy data above the 16M address
limit imposed by the ISA 10-bit DMA path at the same time if you were
smart.
>Is this location programable?
>Could I specify the location of the area?
The cache location? Yes, on some hardware, no on others. It's dependant
on implementation, as is the ability to turn the cache off.
The DMA-to location? Yes, it's specified in the buffer-address in the
request... and must live below 16M. This isn't enforced by two-staging
the buffers (ala "bounce-buffers") in the current rev of Julian's SCSI
driver, which is why people with > 16M of real memory have problems (in
all fairness, these problems are shared with the default 0.1 SCSI driver,
which only works with a single controller; thus Julian's drivers are a
vast improvement no matter how you look at them).
I don't see a significant advantage to a data cache in most situations in
the 386BSD kernel; my advice would be to simply turn it off. The only
data it is interesting to cache is ROM or disk contents. 386BSD does not
use the first, and has it's own method of doing the second.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------