From owner-freebsd-stable Fri Aug 31 4:27:56 2001 Delivered-To: freebsd-stable@freebsd.org Received: from saturn.cs.uml.edu (saturn.cs.uml.edu [129.63.8.2]) by hub.freebsd.org (Postfix) with ESMTP id 7D61337B403 for ; Fri, 31 Aug 2001 04:27:51 -0700 (PDT) Received: (from acahalan@localhost) by saturn.cs.uml.edu (8.11.0/8.11.2) id f7V81EQ453022; Fri, 31 Aug 2001 04:01:14 -0400 (EDT) Date: Fri, 31 Aug 2001 04:01:14 -0400 (EDT) Message-Id: <200108310801.f7V81EQ453022@saturn.cs.uml.edu> From: "Albert D. Cahalan" To: freebsd-stable@FreeBSD.ORG Cc: juha@saarinen.org, pahowes@fair-ware.com Subject: RE: FreeBSD and Athlon Processors Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Juha Saarinen writes: > It's probably not the Athlon CPU that's the issue for either FreeBSD > or Linux, but the motherboard chip sets. From personal experience, > the first Linux 2.4 kernels weren't very happy with VIA chip sets, > which are commonly used for Athlon boards. It's mainly IDE issues > (e.g. UDMA-66/100 support). There are at least two major problems with VIA chips: Any fast PCI device (often IDE) can cause data corruption. VIA initially blamed this on a specific sound card that would push the bus pretty hard, then offered a Windows hack that would disable some performance features. After some trouble finding a contact at VIA, Linux got the same hack. If you don't have this hack... well maybe you just got lucky or did not notice that your data is getting trashed. (with FreeBSD's small user base, a data corruption problem like this one might go unnoticed for a while) If the CPU pushes the memory bus too hard, stuff goes wrong. This was first noticed with some Athlon-specific assembly code in the Linux kernel. The problem has also been seen by Windows users running Photoshop. Sometimes the problem goes away if you upgrade to a very large power supply. AMD has been having some trouble running their new core on VIA motherboards; maybe the new core hits the same problem on unoptimized code. So problems will be less common with an OS that doesn't push the hardware very hard, but do you really want to trust this junky product? Maybe next year you will upgrade to a new gcc that generates code that is fast enough to trigger a problem, or you will install a gigabit network card that is aggressive with the PCI bus. Don't upgrade that CPU next year either. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message