Date: Mon, 28 Aug 1995 14:22:56 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: jbryant@argus.iadfw.net (Jim Bryant) Cc: rashid@haven.ios.com, freebsd-hackers@freebsd.org Subject: Re: S.O.S -2.1Stable and ASUSP54TP4 Message-ID: <199508282122.OAA02559@gndrsh.aac.dev.com> In-Reply-To: <199508282044.PAA16108@argus.iadfw.net> from "Jim Bryant" at Aug 28, 95 03:44:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
...
> > The symptoms:
> >
> > system locks at random times w/o any messages at the console/
> > log files. Locks means the system becomes unreachable neither
>
> Are you using non-parity memory? As you know, memory errors will not trap
> unless you are using parity memory. If you want to use FreeBSD for anything
> other than home-use, I strongly suggest parity memory. (Get a warrantee!)
FYI, the Intel Triton chipset does not have parity logic in it. You
can't detect a parity error on the ASUS PCI/I-P5{4,5}TP* (commonly
refered to as the ASUS Triton series) of boards. This applies to
_ALL_ Triton based motherboards.
The common failure symptom of bad memory on one of these systems is
random signal 10's, and 11's (SIGSEGV, SIGBUS) and kernel panics (most
often page not present). That goes for bad memory on any system infact,
as often parity logic does not catch multibit errors (50% chance).
Running 70nS memory with a 100 or 133MHz CPU is a good way to cause
that particular failure mode (unless the MB stuffs waitstate in for
you, the ASUS's do not, you can manually slow it down though, but
ineffect you might as well drop the clock to 90Mhz).
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508282122.OAA02559>