Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Julian's 1542B driver and > 16MB
Message-ID: <1993Mar23.021251.2245@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1993Mar22.091308.18241@qualcomm.com>
Date: Tue, 23 Mar 93 02:12:51 GMT
Lines: 67
In article <1993Mar22.091308.18241@qualcomm.com> karn@servo.qualcomm.com (Phil Karn) writes:
>I've been running Julian's Adaptec 1542B SCSI driver on my 16 MB 486
>system for several weeks without any problems. Yesterday, during a CPU
>upgrade (from 486-50 to 486DX2-66) I added 4 more meg of memory to see
>if it would help X to run a little faster.
>
>Big mistake. The system seemed to run OK until I ran fsck on my main
>filesystem (a SCSI disk). It completed, but then the system abruptly
>rebooted. Then it got worse -- the fsck found increasing damage, and
>eventually /386bsd got wiped out.
>
>I suspected a problem with DMA above 16MB, so I removed the extra 4 meg,
>booted from a backup disk and rebuilt my kernel. It's been running solid
>ever since.
Yep.
>After looking at the new 1542 driver (/sys/i386/isa/aha1542.c) I
>couldn't find any provision for physical addresses above 16 MB (the
>limit of memory addressable by the 24-bit ISA bus). The virtual buffer
>addresses are converted to physical and the low 3 bytes of the
>physical address given to the 1542; the upper byte is ignored.
>
>If this is so, then attempting to read into a buffer above 16 meg will
>trash low memory without warning. Can anyone confirm this? If this problem
>is real, then at the very least a panic should be added to the driver to
>keep it from trashing a filesystem (as nearly happened to me -- fortunately
>the trashed files were ones I could easily recover).
Confirmed. This is what's happening; it's a limitation on the ISA bus "after
all, no one will ever use more than 16M of memory...".
A panic in the driver before passing the "too high" address to the driver
is a definate (if unfortunate) possibility.
I *badly* fixed this problem for myself as a study in the feasability of
fixing it at all. I discussed this with Adam David:
I allocate a set of buffers for disk I/O in low memory as part of the
boot code. I had to hack the address protection ranges to put this
in a rather wierd place, and it makes the boot assume you have a SCSI device
all the time. Totally unacceptable, but it does force disk buffers to live
below 16M.
The place to "start building" is in the VM routines; we need to be able to
specify whether "cachable" is set and whether the allocator needs to get its
memory from below 16M for a particular (DMA buffer) allocation.
Basically, it fits very well into a split memory pool arangement, sort of like
the difference between "fast" and "chip" RAM on the Commodore Amiga. We
need to ensure chip RAM (RAM below 16M) for DMA devices on ISA machines.
An EISA motherboard with an AHA1742 won't have the DMA problem, since it
can use the EISA DMA, which is not restricted to 24 bits.
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
-------------------------------------------------------------------------------