Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Apr 1995 11:55:57 +1000 (EST)
From:      raoul@cssc-syd.tansu.com.au (Raoul Golan)
To:        fcawth@squid.umd.edu (Fred Cawthorne)
Cc:        agl@redline.ru, freebsd-hackers@wcarchive.cdrom.com
Subject:   Re: 940804 (vaporware ;-) reboots the system either:
Message-ID:  <199504130155.LAA07729@kiwi.cssc-syd.tansu.com.au>
In-Reply-To: <9504122211.AA01185@squid.umd.edu> from "Fred Cawthorne" at Apr 12, 95 06:11:26 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> > 
> > 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.
> 
> 

I'm another victim of this apparently widespread problem... at the
moment my machine will only work with a disabled external cache.
Terry Lambert has been kind enough to give me suggestions as to
what the problem might be (thanks, Terry).

I attempted to recompile the 2.0 kernel without the memory test,
tried to reboot with external cache, and got a kernel page fault
for all my effort.  My question is : since the latest snap seems
to work on some of these problematic machines, is this due simply 
to the elimination of the memory test?  Or have some compatibility
check hacks been added as well?  If the latest snap has only taken
out the memory test, I can conclude that it won't work on my
machine (since I've already tried to do that)

I find it difficult to understand how it could be possible that
taking the memory test out alone could fix the problem - if the
problem isn't caught by the test, surely it would reappear later?

I don't know my chipset - I hope to be able to take the time to open
up the machine over the Easter break.

-- 
Raoul Golan, Consultant for Object Oriented P/L, at   ="Those who have put out
Intelligent Networks Development, Telecom Australia   = the eyes of the people
Also student at Macquarie Univ. School of History,    = reproach them for their
Philosophy and Politics. EMAIL:raoul@ind.tansu.com.au = blindness." - Milton



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504130155.LAA07729>