From owner-freebsd-stable Tue Jul 4 13:40:53 2000 Delivered-To: freebsd-stable@freebsd.org Received: from q.closedsrc.org (ip233.gte15.rb1.bel.nwlink.com [209.20.244.233]) by hub.freebsd.org (Postfix) with ESMTP id 62B6337BB2F for ; Tue, 4 Jul 2000 13:40:39 -0700 (PDT) (envelope-from lplist@q.closedsrc.org) Received: from localhost (lplist@localhost) by q.closedsrc.org (8.9.3/8.9.3) with ESMTP id NAA87504; Tue, 4 Jul 2000 13:40:07 -0700 (PDT) (envelope-from lplist@q.closedsrc.org) Date: Tue, 4 Jul 2000 13:40:07 -0700 (PDT) From: Linh Pham To: "Jordan K. Hubbard" Cc: Larry Rosenman , Greg Lehey , Greg Work , freebsd-stable@FreeBSD.ORG Subject: Re: AMD K6-2 / 550 In-Reply-To: <48265.962741737@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A couple of things that might cause poor performance on an AMD K6-2 system could be the cache located on the motherboard (either fake or painfully slow cache chips), old BIOS revision/firmware version, bad or non-matching memory, or just plain poor chipset. A couple of things to try is, if possible, is to flash your BIOS to the latest revision and make sure that your are using PC100 memory. You might want to try to disable the L2 cache that's on the motherboard to see if it helps with stability or not. If that increases stability, then the cache chips on your motherboard are bad. // Linh Pham // // Proud supporter of FreeBSD and OpenBSD // FreeBSD - http://www.freebsd.org // OpenBSD - http://www.openbsd.org /* "Oregon, n.: Eighty billion gallons of water with no place to go on Saturday night." */ On Tue, 4 Jul 2000, Jordan K. Hubbard wrote: > > Let's put it this way, I've posted a NUMBER of items to the -stable list > > over the last 2-4 weeks as I've fought this one. I can't get a > > CPU/BIOS/MB with a K6-2/550 on it to SUCCESSFULLY/RELIABLY make world. > > Well, it's certainly a hardware problem of some sort since we have > literally dozens of K6-2 systems here - we built a cluster of them for > package building and have a bunch of them also serving in various > FreeBSD desktop roles. They all work flawlessly, from FreeBSD 3.x all > the way up to 5.0-current. Where the hardware problem is with your > system is, of course, almost impossible to diagnose remotely but rest > assured that it is NOT a software issue. I'm also not saying that you > implied such was the case, I just wanted to state such publically and > for the record. > > - Jordan > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message