Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!uwm.edu!vixen.cso.uiuc.edu!newsrelay.iastate.edu!news.iastate.edu!news.iastate.edu!michaelv
From: michaelv@MindBender.HeadCandy.com (Michael L. VanLoon)
Newsgroups: comp.os.386bsd.misc
Subject: Re: reason not to buy SIS P5-90 MB for *BSD?
Date: 23 Nov 1994 04:59:50 GMT
Organization: HeadCandy Associates... Sweets for the lobes.
Lines: 51
Message-ID: <MICHAELV.94Nov22225950@MindBender.HeadCandy.com>
References: <rcarterCznF5r.MMr@netcom.com>
<MICHAELV.94Nov22101157@MindBender.HeadCandy.com>
<3au1ub$pg4@news.cc.utah.edu>
NNTP-Posting-Host: mindbender.headcandy.iastate.edu
In-reply-to: terry@cs.weber.edu's message of 23 Nov 1994 00:21:31 GMT
In article <3au1ub$pg4@news.cc.utah.edu> terry@cs.weber.edu (Terry Lambert) writes:
In article <MICHAELV.94Nov22101157@MindBender.HeadCandy.com> michaelv@MindBender.HeadCandy.com (Michael L. VanLoon) writes:
] This doesn't answer your question exactly, but... I have an SiS
] chipset on my Nice Super-EISA 486 motherboard, and it works
] exceptionally well. I can even use the cache in write-back mode with
] my EISA bus-mastering SCSI controller (bt747s), although I did have to
] disable parity checking to do so. I'd never heard of SiS before, but
] the EISA chipset in my 486 motherboard seems to work quite well. I
] don't know if this extends to PCI and/or Pentiums, however.
Why did you have to disable parity checking?
I honestly don't know why -- I just know it works. With parity
checking on, I would get occasional NMI's. I theorize that it can't
calculate the parity on the cache write-back quick enough before the
EISA burst bus access proceeds (which has been backed-off to let a
write-back of dirty cached memory proceed). This is total guess-work;
I have no solid proof of why.
But I do know that I'm running on about my tenth generation kernel
this way (the first kernel built while write-back was on built the
second, which was booted to build the third while write-back was on,
etc.) I haven't noticed any bit rot or strange VM problems with a
512k cache. So I assume it was a problem with parity-checking keeping
up with write-back during EISA burst. I am also on my third
generation of the full system build (binaries, libraries, etc.), with
no foulness. Not a real scientific way to prove things, but proof
enough for me, nonetheless. My current uptime is about 13 1/2 days.
If you got errors otherwise, I'd suggest toning down the bus-on time for
the controller instead.
I don't believe this is an option. If I'm not mistaken, the EISA bus
timings are fixed quantities prescribed by the spec, unlike the
guesswork ones used under VLB. (At least if they're adjustable,
they're not adjustable from the EISA configuration utility.)
Incidentally, I tried my motherboard with the bus at 8MHz (spec.
speed), most wait states possible on both the main memory and cache
accesses, and still got the NMI's when write-back and parity checking
were both enabled, while using the SCSI bus. With parity checking
off, I can run with less wait states and no badness.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Michael L. VanLoon michaelv@HeadCandy.com michaelv@iastate.edu
Free your mind and your machine -- NetBSD free un*x for PC/Mac/Amiga/etc.
Working NetBSD ports: 386+PC, Mac, Amiga, HP300, Sun3, Sun4c, PC532
In progress: DEC pmax (MIPS R2k/3k), VAX, Sun4m
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -