From owner-freebsd-hackers  Thu Apr 13 00:42:49 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id AAA05775
          for hackers-outgoing; Thu, 13 Apr 1995 00:42:49 -0700
Received: from wcarchive.cdrom.com (wcarchive.cdrom.com [192.216.191.11])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA05769
          for <freebsd-hackers@freefall.cdrom.com>; Thu, 13 Apr 1995 00:42:41 -0700
Received: from redline.ru (mail.redline.ru [194.87.69.22]) by wcarchive.cdrom.com (8.6.11/8.6.6) with SMTP id AAA19049 for <freebsd-hackers@wcarchive.cdrom.com>; Thu, 13 Apr 1995 00:39:36 -0700
Date: Thu, 13 Apr 1995 11:37:27 +0400 (GMT+0400)
From: Anthony Graphics <agl@mac.glas.apc.org>
X-Sender: agl@mail.redline.ru
To: Fred Cawthorne <fcawth@squid.umd.edu>
cc: freebsd-hackers@wcarchive.cdrom.com
Subject: Re: 940804 (vaporware ;-) reboots the system either:
In-Reply-To: <9504122211.AA01185@squid.umd.edu>
Message-ID: <Pine.LNX.3.91.950413113650.8612A-100000@mail.redline.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

On Wed, 12 Apr 1995, Fred Cawthorne wrote:

> Date: Wed, 12 Apr 95 18:11:26 EDT
> From: Fred Cawthorne <fcawth@squid.umd.edu>
> To: Anthony Graphics <agl@redline.ru>
> Cc: freebsd-hackers@wcarchive.cdrom.com
> Subject: Re: 940804 (vaporware ;-) reboots the system either:
> 
> > 
> > again, the system worked for weeks under load in linux,
> > now FreeBSD reboots it during the memory test :-[
> > I tryed to increase wait states in the CMOS to MAX values to no avail :-[
> > Any pointers would be welcome. Somebody told me that disabling
> > cache on the motherboard could help: but I don't want to do
> > such a stupid tricks.
> (You should at least try it to see if it works, you don't have to 
>  leave it that way but it will let you eliminate alot of other possible
>  causes like corrupt binaries, bad memory, etc...)
> > Thanx in advance for any pointers.
> > AGL
> > 
> I had a system that did this too.  I think it is the UNI chipset's
> fault.  (It only got past the memory check if the external cache was
> turned off) I think it is a rather rare chipset...  Anyway, it used to die 
> when trying to boot 2.0 +, until the latest snap that doesn't have
> the memory test in it (:  The memory test must have snarfed up something
> in there...  Now, it seems to work fine.  I did a couple of kernel
> recompiles, etc.. and it is fine.  The system is an AMD 486-66 UNI
> chipset with 8 megs ram and an IDE disk.
> So, I suggest that you try the 950322 snap.
Althought I'm not sure I have an UNI chipset 950322 really works for me
AGL
> 
> 
> Fred.
> 
>  
>