Date: Wed, 14 May 2003 09:00:10 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org>, Robert Watson <rwatson@FreeBSD.org>, re@FreeBSD.org, current@FreeBSD.org, Heiko Schaefer <hschaefer@fto.de> Subject: Re: 5.1-RELEASE TODO Message-ID: <3EC2680A.FBB87C76@mindspring.com> References: <XFMail.20030514102537.jhb@FreeBSD.org> <3EC265BD.9B9FEFAC@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EC2680A.FBB87C76>