From owner-freebsd-bugs Fri Feb 1 0:34:30 2002 Delivered-To: freebsd-bugs@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id B419A37B405; Fri, 1 Feb 2002 00:34:22 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020201083418.UGYE3578.rwcrmhc52.attbi.com@peter3.wemm.org>; Fri, 1 Feb 2002 08:34:18 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g118YIs58956; Fri, 1 Feb 2002 00:34:18 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id C3FFC3809; Fri, 1 Feb 2002 00:34:17 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Glendon Gross , Steve Kargl , Kenneth Culver , "Cameron, Frank" , David Malone , "'freebsd-bugs@freebsd.org'" , "'freebsd-current@freebsd.org'" Subject: Re: AMD AGP Bug In-Reply-To: <3C5A4C0C.16F8426E@mindspring.com> Date: Fri, 01 Feb 2002 00:34:17 -0800 From: Peter Wemm Message-Id: <20020201083417.C3FFC3809@overcee.wemm.org> Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert wrote: > Glendon Gross wrote: > > That's right, guys! This is FreeBSD after all... so Mr. Lambert is > > entitled to charge 10K for that bugfix code if he wants. In fact he is > > "Free" to do so. But it's a little pricy for me, although perhaps not for > > AMD if it means they can fix their cache-paging problems! > > It cost me two weeks to figure out, and both Intel and AMD > wanted to charge me $$$ to file a problem report. [..] > Since it's not a FreeBSD problem, you'll forgive me if I > find it funny that Linux and Windows disables the PSE to work > around some problems. It's not that hard to understand or > work around, if you know where to look, and knowing where to > look is what will cost them. [..] > The *other* AMD problem, with AGP and 4K and 4M pages that > point to the same memory could arguably be a chipset or a > software problem (depending on whether or not the chipset > vendor has documented the behaviour before people were let > loose to write the software -- errata: the difference > between a software problem and a software workaround to a > hardware problem). It's already documented how to work > around that one; I'm sure a fix is pending for Linux, and > Windows will probably leave PSE off until they can figure > out a way to update everyone. I'm a little confused as to which bugs are which that we're talking about now. Which is the one that you're trying to sell the info for? The issues that I know about: - interactions between PG_G, CR4_PGE, 4M and 4K pages and TLB flushing (potentially cross platform issue due to boot time quirks).. I think we have a workaround for this in our code already, but I have a better complete fix for it in a pending change that I'm working on. - AMD invlpg vs 4MB page bug (AMD bug). If you invlpg using an address in the upper 2MB of a 4MB page, the 4MB tlb may not be flushed (we dont suffer from this (I think) because we do some very suboptimal things with 4MB pages), versus doing an invlpg at the base address of the 4MB mapping. - AMD write cache allocation due to speculative writes being cancelled and then written back later vs no cache snooping on AGP regions. I'm somewhat perplexed about this issue, there's lots of conflicting info going around, a good deal of it which does not make much sense [to me :-)]. I really dont see what PSE has to do with this for several reasons.. if the page/ region is cacheable, why does a 4MB vs 4K page make any difference? cacheable vs no-cache-snooping is a recipe for disaster.. why would 4K pages on a non-coherent region be safer? Or is the problem that write allocation happens on uncacheable/non-write-back regions in 4MB pages? Or something else? - hardware prefetch (newer AMD cpus, pentium 4, 0.13 micron pentium3's) related problems. (can be solved with PAT and/or MSRR programming). I'm just trying to figure out if there's something I'm missing. I know we do some very dubious things with PG_G at bootup. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message