We have seen weird problems regarding the pmap PG_G related stuff (well
sort of, it has to do with PSE and PG_G) on ppro and pII chips
(apparently, this is not the case with at least Xeons) but what
happened, for the record, was this:

We would enable PSE and switch the pde corresponding to the first 4M
to the new entry describing a 4M page, instead of the one describing the
location of the ptes covering those 4M.  Then, what we would do is walk
all the ptes, including those old stale and useless ones that previously
described those first 4M and set the PG_G bit there (Note: we've already
set PG_G on our 4M page).  Normally, we don't really need to touch the
old ptes but we did it just because it was more convenient (i.e. a few
lines less code).  Oddly enough, on the ppro and pII what would happen
is that we would page fault on that page where we kept the old ptes
covering those first 4M, and only on that page!  The other ptes - the
ones that actually mattered - were all fine.  The ptes are mapped above
the 4M so I don't see how changing the pde for those first 4M would have
done anything.  To "fix" the problem, we (actually Peter) committed code
that basically just jumps beyond that first page of stale ptes when
setting the PG_G bit for the 4K pages, and since then, the problem seems
to have gone away.  Although we are not sure, this seems like a silicon

Since then, Peter had some work planned to load the kernel above the
first 4M to see if that fixed the problems.  I'm wondering if this
problem on the PIVs could be related.  Please let us know if the removal
of those two options really makes 5-10 buildworlds in a row work out for


On Thu, Aug 22, 2002 at 01:34:11PM +0200, Mark Santcroos wrote:
> On Thu, Aug 22, 2002 at 04:23:46AM -0700, Terry Lambert wrote:
> > Ugh!  Wait until it seems to work for a statistically significant
> > sample size, and for more than one person before calling it "happy"!
> > 
> > Also, I'm not sure looking at the code whether or not the PG_G is
> > truly significant, or just preterbs the workaround.  The problem
> > I've referred to in my "hunch" here is actually related solely to
> > the PSE, but with the recent code reorganization in locore.s, etc.,
> > it could have become more significant.
> I was just giving a slight report, not yelling halleluja yet ;-)
> It's doing the 2nd buildworld now.
> Do you also want me to try to split up the disabling of the two options?
> Mark
> -- 
> Mark Santcroos                                RIPE Network Coordination Centre
> http://www.ripe.net/home/mark/                New Projects Group/TTM
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to