From owner-freebsd-stable Tue Oct 5 6:32:10 1999 Delivered-To: freebsd-stable@freebsd.org Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by hub.freebsd.org (Postfix) with ESMTP id 4678B14D10 for ; Tue, 5 Oct 1999 06:31:54 -0700 (PDT) (envelope-from dgilbert@trooper.velocet.net) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id JAA06517; Tue, 5 Oct 1999 09:30:15 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14329.64871.579761.476450@trooper.velocet.net> Date: Tue, 5 Oct 1999 09:30:15 -0400 (EDT) To: Cy Schubert - ITSD Open Systems Group Cc: David Gilbert , freebsd-stable@FreeBSD.ORG Subject: Re: More on the crashes already mentioned. In-Reply-To: <199910051323.GAA17221@cwsys.cwsent.com> References: <14329.4421.847994.918399@trooper.velocet.net> <199910051323.GAA17221@cwsys.cwsent.com> X-Mailer: VM 6.71 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Cy" == Cy Schubert <- ITSD Open Systems Group > writes: Cy> It sure sounds like memory. I can we assume you tried completely Cy> different memory chips? Even then that's no guarantee. Also try Cy> increasing the memory refresh rate. I had a panic with FreeBSD Cy> 2.0.5 was solved by increasing the refresh rate. If that doesn't Cy> help try reducing the memory. Some systems cannot refresh memory Cy> fast enough to be stable under certain memory access patterns. Cy> The quality of memory for PC's has always been scatological, Cy> however now that most memory is non-parity, you don't even get Cy> notified of single bit errors. It may even be worth it to Cy> purchase some ECC memory. IIRC ECC uses the Reed-Solomon Cy> algorithm (same as used by NASA for deep space probes), to detect Cy> and correct memory errors, so the rate of detection and correction Cy> of an error burst of 16 bits should should approach 99.99999%. Well... the same machine had an 80 day uptime before the upgrade (running 3.0-RELEASE). We have also tried alternate motherboards. Now... all this hardware is K6-2/400's --- it appears that substantial amounts of new code playing with processor bits has been introduced between 3.2 and 3.3 I also tried cutting the memory in half. The system had been running as configured for 80ish days w/o reboot. It has 2x 128M in it, which I reduced to 1x 128M... if anything, it crashed faster (although I can't say this for sure). The machine is running 100+ apaches that are ~88M virtual size. It's happening every 5 minutes now, it seems. sigh. Dave. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message