From owner-freebsd-current@FreeBSD.ORG Wed Sep 3 23:03:56 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 328D2106568D for ; Wed, 3 Sep 2008 23:03:56 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D95538FC28 for ; Wed, 3 Sep 2008 23:03:55 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id m83N3gqU044247; Wed, 3 Sep 2008 17:03:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <48BF17CE.1070507@samsco.org> Date: Wed, 03 Sep 2008 17:03:42 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: josh.carroll@gmail.com References: <20080903034943.GD11548@cicely7.cicely.de> <20080903204759.GA4898@walton.maths.tcd.ie> <8cb6106e0809031446i3e2a47dar385125ecfb0275dc@mail.gmail.com> <48BF1218.6000504@samsco.org> <8cb6106e0809031550o4960a4fanaf2ef5fe9130fc5b@mail.gmail.com> In-Reply-To: <8cb6106e0809031550o4960a4fanaf2ef5fe9130fc5b@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: David Malone , Bernd Walter , ticso@cicely.de, freebsd-current@freebsd.org Subject: Re: MTRR fixup? 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: Wed, 03 Sep 2008 23:03:56 -0000 Josh Carroll wrote: >> Actually, it likely doesn't. > > Ok, something else then. My second guess (and what I thought prior to > seeing this mail thread) was that it was perhaps address space > reserved for the kernel? Off topic for this thread I suppose, I can > ask elsewhere. > >> All systems reserve the top 256MB of the address space for PCI >> memory and chipset registers. Modern systems have started >> reserving even more than that for other new PCI functionality. >> Note that this is address space, not RAM. The RAM is likely >> being remapped to some place above the 4GB barrier. > > That makes sense. But is there a way to correlate where the physical > memory is mapped with the memory ranges listed in memcontrol list > output then? Or how would someone check if they are, in fact, affected > by this sort of BIOS bug? > The SMAP table, printed early during boot when bootverbose is set, will tell you what is mapped where. >>> I'll have to play with memcontrol to see if I can set those two large >>> ranges as cacheable. So this is a BIOS bug? The board in question is >>> an Asus P5K-E with BIOS revision 1102, which uses an Intel P35 >>> chipset. >> At best, nothing will happen. But more likely, your box won't boot. > > So I'd be stepping on/trashing memory ranges used for PCI device > mappings? I guess I probably just started a ticking time bomb then, > huh? :) No, you'd made PCI registers be cachable, making any reads from them unreliable and useless. Scott