On Thu, 24 Feb 2000, Matthew Dillon wrote:
> Please try the following patch and tell me if the crashes still occur.
> If this fixes the problem then I'm homing in on the bug.
It seems to work here.
> I am beginning to suspect that there is a case where a pmap can get
> cleared without the tlb being flushed, causing origpte to be 0 when the
> new pte is later created again at the same spot. When the new
I think I found the real bug: invltlb() doesn't work on global pages.
invlpg() is supposed to have no effect on global pages, and the point
is that it apparently decides globalness based on cached copies of
the PTE's. It has to invalidate all TLB entries, and it would be
stupid for it to read all the corresponding PTE's just in case a PTE
has been changed without doing an invlpg().
Removing the global bit from pgeflag seems to fix the bug (I just used
ddb to clear pgeflag; this keeps PG_G out of future mappings).
Some code in pmap.c seems to be vaguely aware of the need to use
invlpg() instead of invltlb(). pmap_new_proc() always uses invlpg()
for pages with the global bit set, but its test for the global bit is
a no-op since the global bit can only be set if (cpu_class > CPUCLASS_386).
Similarly in pmap_dispose_proc(). pmap_remove_pte() always uses
invlpg() for pages with the global bit set and apparently depends on
its caller to call at least invltlb() for other pages.
More code in pmap.c is probably broken if this is the problem.
Everything that uses invltlb() is suspect.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
