From owner-freebsd-current@FreeBSD.ORG Wed May 14 09:01:28 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 1FEF137B407; Wed, 14 May 2003 09:01:28 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6B0B43F85; Wed, 14 May 2003 09:01:23 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0095.cvx21-bradley.dialup.earthlink.net ([209.179.192.95] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Fygz-0006eo-00; Wed, 14 May 2003 09:01:22 -0700 Message-ID: <3EC2680A.FBB87C76@mindspring.com> Date: Wed, 14 May 2003 09:00:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin , Robert Watson , re@FreeBSD.org, current@FreeBSD.org, Heiko Schaefer References: <3EC265BD.9B9FEFAC@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a469334fc887241072a4899aec6064b7f4548b785378294e88350badd9bab72f9c350badd9bab72f9c Subject: Re: 5.1-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 14 May 2003 16:01:29 -0000 Terry Lambert wrote: > John Baldwin wrote: > > Umm, Terry, that's the whole point of PGE. You don't flush entries > > from the TLB that are "global", i.e. shared among all processes and > > don't change. "Duh". Basically your suggestion would be an > > expensive hack equivalent to DISABLE_PG_G. > > No. My suggestion would be to not load something into a global > page before some of the VM system mappings have been established. > > Basically, there is some machdep.c code that's out of order. > Reordering it is hard, so I haven't done it yet. > > In other words, the problem is that someone is enabling PG in > %CR0 way too early. > > Read the first sentence again: "...works around an order of > operation problem...". BTW: a "brute force" kludge to fix this problem is to clear PG in %CR0, iterate over the already allocated pages with PG_G set in them clearing it, reload %CR3, set PG in %CR0, iterate the exact same pages again resetting PG_G, and reload %CR3, right at the end of machdep.c. This will effectively "fix" the PG_G related problems, since they appear to be related to pages in the TLB cache with PG_G set without PG set in %CR0 first (it works to fix the errors on the two machines where I've noted PG_G related problems). -- Terry