From owner-freebsd-current@FreeBSD.ORG Sun Jan 27 21:34:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19C5C16A477 for ; Sun, 27 Jan 2008 21:34:28 +0000 (UTC) (envelope-from bruce@zuhause.org) Received: from mail.zuhause.org (216.243.156.193.real-time.com [216.243.156.193]) by mx1.freebsd.org (Postfix) with ESMTP id AFD4613C4CC for ; Sun, 27 Jan 2008 21:34:27 +0000 (UTC) (envelope-from bruce@zuhause.org) Received: by mail.zuhause.org (Postfix, from userid 1001) id AC9857C04; Sun, 27 Jan 2008 15:34:26 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18332.63714.345461.295325@celery.zuhause.org> Date: Sun, 27 Jan 2008 15:34:26 -0600 From: bruce@zuhause.mn.org In-Reply-To: <18332.52845.956601.870334@celery.zuhause.org> References: <18328.45282.562906.708945@celery.zuhause.org> <18329.22270.123314.900543@bhfs.zuhause.org> <18332.52845.956601.870334@celery.zuhause.org> X-Mailer: VM 7.15 under 21.4 (patch 12) "Portable Code" XEmacs Lucid Cc: Richard Todd , freebsd-current@freebsd.org Subject: Re: Weird performance behaviour in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2008 21:34:28 -0000 bruce@zuhause.mn.org writes: > Richard Todd writes: > > > > bruce@zuhause.mn.org writes: > > > Richard Todd writes: > > > > This wouldn't by any chance be an Intel 965-chipset-based motherboard > > > > with 4G or more of memory, would it? Because there's an interesting > > > > little bug in the BIOS on some of those boards which causes the > > > > cache-control registers to incorrectly declare a chunk of main memory > > > > as uncacheable. This results in random slowdowns depending on whether > > > > your process lands in the "bad" zone of memory or not. See > > > > http://article.gmane.org/gmane.os.freebsd.stable/50135/ for more details. > > > > > > Bingo! This is a Intel DG965WH with 4 GB of memory. I don't think I > > > can downgrade to the 1669 firmware because of the processor I'm > > > using. The Fedora thread says that there's a hack to do the following > > > in linux to fix the "bad" zone > > Embarrassingly, after I posted this, I realized that I was not at the > latest BIOS level, and not at a recommended level for my processor, so > I flashed it with the latest, version 1719. Although in the Fedora > thread Jussit said that it didn't fix the problem, it seems to have > fixed it for me. BTW, I was able to get the SMAP information at the > loader prompt. > > I'm curious, though, should I be worried about the memcontrol list > entries that are listed as "set-by-firmware active bogus"? > > Type '?' for a list of commands, 'help for wore detailed > OK smap > SMAP type=01 base=0000000000000000 len=000000000008f000 > SMAP type=02 base=000000000008f000 len=0000000000011000 > SMAP type=02 base=00000000000e0000 len=0000000000020000 > SMAP type=01 base=0000000000100000 len=00000000cf461000 > SMAP type=02 base=00000000cf561000 len=000000000000d000 > SMAP type=0l base=00000000cf56e000 len=000000000009c000 > SMAP type=04 base=00000000cf60a000 len=00000000000df000 > SMAP type=01 base=00000000cf6e9000 len-0000000000009000 > SMAP type=03 base=00000000cf6f2000 len=000000000000d000 > SMAP type=01 base=00000000cf6ff000 len=0000000000001000 > SMAP type=02 base=00000000cf700000 len=0000000000100000 > SMAP type=02 base=00000000cf800000 len=0000000000800000 > SMAP type=02 base=00000000fff00000 len=0000000000100000 > SMAP type=01 base=0000000100000000 len=000000002c000000 > OK > 0xff000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active > 0x0/0xf080000000 BIOS write-back set-by-firmware active bogus > 0x80000000/0xf040000000 BIOS write-back set-by-firmware active bogus > 0xc0000000/0xf010000000 BIOS write-back set-by-firmware active bogus > 0xcf800000/0xf000800000 BIOS uncacheable set-by-firmware active bogus > 0xcf700000/0xf000100000 BIOS uncacheable set-by-firmware active bogus > 0x100000000/0xf020000000 BIOS write-back set-by-firmware active bogus > 0x120000000/0xf008000000 BIOS write-back set-by-firmware active bogus I hate to follow up to my own postings, but it seems to me that this memcontrol list is missing 0x4000000 (64 MB). I'm using the onboard video. I'm not sure if this means that it's never used by the OS, or that I'm just lucky that I haven't yet experienced a slowdown. With the old BIOS, I couldn't run a make release without hitting it, but as far as I can tell, I haven't seen a problem yet even though I ran another make release and ran the repeated tight CPU loops I was using to test before. Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RC1 #2: Mon Jan 14 03:17:48 UTC 2008 toor@orca.zuhause.org:/usr/obj/usr/src/sys/ORCA Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2407.20-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 usable memory = 4202840064 (4008 MB) avail memory = 4042080256 (3854 MB) ACPI APIC Table: