From owner-freebsd-current@FreeBSD.ORG Wed May 14 00:32:10 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2A4837B401; Wed, 14 May 2003 00:32:10 -0700 (PDT) Received: from MX4.estpak.ee (ld3.estpak.ee [194.126.101.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id F38AC43FA3; Wed, 14 May 2003 00:32:08 -0700 (PDT) (envelope-from kalts@estpak.ee) Received: from kevad.internal (80-235-37-102-dsl.mus.estpak.ee [80.235.37.102]) by MX4.estpak.ee (Postfix) with ESMTP id 86AB31D0008; Wed, 14 May 2003 10:32:05 +0300 (EEST) Received: (from vallo@localhost) by kevad.internal (8.12.9/8.12.9/Submit) id h4E7W51T001734; Wed, 14 May 2003 10:32:05 +0300 (EEST) (envelope-from vallo) Date: Wed, 14 May 2003 10:32:05 +0300 From: Vallo Kallaste To: Peter Wemm Message-ID: <20030514073205.GA1324@kevad.internal> References: <200305132101.h4DL1QM7051267@gw.catspoiler.org> <20030513221637.3B7422A8AC@canning.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030513221637.3B7422A8AC@canning.wemm.org> User-Agent: Mutt/1.5.4i-ja.1 cc: rwatson@FreeBSD.org cc: Don Lewis cc: re@FreeBSD.org cc: hschaefer@fto.de cc: current@FreeBSD.org Subject: Re: 5.1-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kalts@estpak.ee List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 07:32:11 -0000 On Tue, May 13, 2003 at 03:16:37PM -0700, Peter Wemm wrote: > Also of note: I recently saw a brand new P4 system with a genuine intel > motherboard, for a RELENG_4 system. It had shocking data corruption > problems. The memory was swapped - no change. The motherboard and CPU were > swapped (same motherboard model, much newer P4 cpu stepping) - no change. > It was simply unreliable. Backporting DISABLE_PG_G to RELENG_4 and turning > on it and DISABLE_PSE greatly reduced the problem, but it still happened. > In the end, the Intel motherboard was replaced with a P4 Xeon system > motherboard and the problem instantly went away. The trouble appeared > to be a generic problem the Intel 845 chipset motherboard. > > Remember, this was RELENG_4 as of a few months ago. It isn't a 5.x-only > problem. Peter, this sounds very suspiciously similar to my P4 system, do you remember the mobo model? Mine is: FreeBSD 5.0-CURRENT #0: Fri Mar 14 13:08:38 EET 2003 root@vallo.internal:/usr/home/vallo/Vallo-5.0 Preloaded elf kernel "/boot/kernel/kernel" at 0xc04ff000. Preloaded elf module "/boot/kernel/aout.ko" at 0xc04ff0a8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04ff154. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1699952048 Hz CPU: Intel(R) Celeron(R) CPU 1.70GHz (1699.95-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf13 Stepping = 3 Features=0x3febfbff real memory = 132382720 (126 MB) avail memory = 123236352 (117 MB) Allocating major#253 to "net" Allocating major#252 to "pci" Pentium Pro MTRR support enabled VESA: v3.0, 832k memory, flags:0x1, mode table:0xc0429d80 (1000040) VESA: Brookdale-G Graphics Chip Accelerated VGA BIOS npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard <<<<<<<<<<<<<<<< ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE31 pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00f3d20 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 ------------------------------------------------------------ This is headless machine, has serial console and most of the work is done via ssh. No X, no drm, agp driver compiled in, network card: fxp0: port 0xdc00-0xdc3f mem 0xff8ff0 00-0xff8fffff irq 11 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:29:85:a5 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ------------------------------------------------------------ I haven't tried builds absolutely without network interface (it's onboard), but it doesn't matter will the ssh session be up or not. Memory is non-ECC and I haven't swapped any components because of restrictions we have here at work. Have you guys considered setting up some webpage with clear and firm instructions for testing, with some kind of feedback submit form. I'm very concerned about data integrity and willing to do any testing necessary on the systems I have here, but this is going to nowhere if anyone will do their own set of tests and the initial testing environment differs from case-to-case. If we need to prove something, the very thing we need is the base; firm instructions for testing and feedback data in the one format. Only after that we can correlate the results and systems the tests did run. -- Vallo Kallaste