From owner-freebsd-hackers  Wed Apr 12 21:13:07 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id VAA09749
          for hackers-outgoing; Wed, 12 Apr 1995 21:13:07 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA09741
          for <freebsd-hackers@freebsd.org>; Wed, 12 Apr 1995 21:13:04 -0700
Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id VAA13820; Wed, 12 Apr 1995 21:12:43 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id VAA00140; Wed, 12 Apr 1995 21:12:43 -0700
Message-Id: <199504130412.VAA00140@corbin.Root.COM>
To: raoul@cssc-syd.tansu.com.au (Raoul Golan)
cc: fcawth@squid.umd.edu (Fred Cawthorne), agl@redline.ru,
        freebsd-hackers@FreeBSD.org
Subject: Re: 940804 (vaporware ;-) reboots the system either: 
In-reply-to: Your message of "Thu, 13 Apr 95 11:55:57 +1000."
             <199504130155.LAA07729@kiwi.cssc-syd.tansu.com.au> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Wed, 12 Apr 1995 21:12:26 -0700
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>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)

   Of course there have been hundreds (thousands?) of changes to the kernel
sources since 2.0R - some of them fix bugs that caused the kernel to not boot
on some machines.

>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?

   The memory test was removed because it took too long on machines with a
lot of memory (a lot is >= 64MB) and wasn't effective in finding real memory
problems anyway. It wasn't removed with the intention of fixing any sort of
boot problem. The kernel still does a check to make sure that what the BIOS
tells it about the size of memory is actually true (which was the main
intention of the original memory test). Since you seem to have relatively new
hardware, it's extremely unlikely that your problem is in any way related to
memory sizing.
   If I were going to troubleshoot the problem, I'd find out how far it
actually gets before resetting. If it makes it as far as C code (i.e. past
the code in locore), I'd put in printf's followed by DELAY(1000000) at
various points to find where it dies.

-DG