Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!qualcom.qualcomm.com!servo.qualcomm.com!karn From: karn@servo.qualcomm.com (Phil Karn) Subject: Julian's 1542B driver and > 16MB Message-ID: <1993Mar22.091308.18241@qualcomm.com> Sender: news@qualcomm.com Nntp-Posting-Host: servo.qualcomm.com Organization: Qualcomm, Inc Date: Mon, 22 Mar 1993 09:13:08 GMT Lines: 28 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. 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). Phil