can Sys. V Rel. 3.2 support > 16MB RAM when can only DMA to <= 16MB?

[Scott Weikart]

First, some details for those of you who are interested in IBM PC/AT
compatible, Intel 80386-based computers.  I'm trying to use more than 16MB of
main memory on an AT/386 running Interactive 386/ix 2.0.2 (V.3.2).  I'm using
the latet Chantal SCSI driver with the Adaptec AHA1542 SCSI host adapter.  The
AHA1542 has an on-board DMA for doing data transfers; since it uses the AT
bus, it only works with 24 bits of address, i.e. it can access at most 16MB of
memory.  But I'd like to buy a motherboard that will hold 32MB of memory,
because I'm starting to thrash.

So, my machine would have more than 16MB of memory, but the DMA on my disk
controller will access at most 16MB of memory.  How can I make this work?

I have two ideas on how to do this.  One is to only use block devices on the
local machine (so that all disk DMA is done to the disk cache, which is always
in low memory), and put raw devices on remote machines accessible via RFS over
ethernet.  Although tty devices are raw, they always do their transfers to
kernel buffers as near as I can figure.  I'd put my tape devices on remote
machines.  The tricky part is the swap device; although it's a block device,
it does transfers directly into user space without going through the disk
cache [acording to Bach].  To get a swap device, I'd remote mount a disk
partition from another machine using RFS: I would boot the machine with a
local swap region, then start up RFS, then mount an unused partition from a
remote machine, then use /etc/swap to setup the remote partition as a swap
device, then use /etc/swap to delete the partitin on the local machine.  Note
that I'm not too worried about performance loss from swapping/paging across
ethernet, because I'll be reducing swap/page activity drastically by doubling
the amount of RAM available.  But can V.3.2 handle a swap partition on a
remote machine?

The second idea is to use a feature that's (maybe) specific to V/386.  There's
a file /etc/default/boot that contains boot time parameters (described by
boot(1)).  The MEMRANGE parameter lets you specify a number of different
ranges of physical address space where RAM can found; for each range of
address space, you can specify whether or not DMA accesses work to this range.
If I specify not to use DMA for memory above 16MB, will all my problems be
magically solved?  If so, how is it done?  For example, Bach says that when
swapping a process the whole process is stored in contiguous sectors of the
swap device; will the kernel grab some blocks from the disk cache and do the
swapping in chunks, using the disk cache blocks as the DMA-accessible
intermediary?  And will the kernel do all the chunking with disk cache blocks
transparently to the disk driver, or will the driver have to get the MEMRANGE
parameters and do its own special tricks for transferring into memory where
DMA can't work?

Any other ideas on how to handle this problem?

Please send me comments in email, since I din't normally read these
newsgroups.  I'll post any feedback I receive.
-- 
Scott Weikart
Community Data Processing (415)322-9069
weikart at arisia.xerox.com  pyramid!cdp!scott