Date: Thu, 24 Feb 2000 16:51:25 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Bruce Evans <bde@zeta.org.au>, David Gilbert <dgilbert@velocet.ca>, freebsd-current@FreeBSD.ORG Subject: Re: Patch to try (was Re: Wierd AMD panics caused by VMWare?) Message-ID: <200002250051.QAA43750@apollo.backplane.com> References: <Pine.BSF.4.21.0002250740030.7691-100000@alphplex.bde.org> <200002242105.NAA42378@apollo.backplane.com> <200002250033.QAA43662@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: This would explain why messing with the pmap_remove_all() case does
: not do what we expect -- I suspect that routine is not being called
: at all in certain cases.
:
: I have not found the case where the pmap gets cleared without being
: flushed yet but when I force the flush in pmap_enter(), it seems to
: stop the crashes (but I can't be 100% sure because I had to mess
: around with that file descriptor program to get it to crash the first
: time).
Is it possible that a speculative read by the cpu is causing the TLB
to load the invalid pte entry after we have cleared it but before
we have created a new entry? This would not cause a fault, but it
would load the TLB and cause a problem when we later initialize the
pte but fail to invalpg1 the VA.
A sequence like this:
pmap_remove_all() called on pa
tlb at VA flushed
(something happens to cause the cpu to load the tlb at VA without
faulting).
pmap_enter() called with new pte (kernel memory is freed and
then later allocated again). Old contents was 0 so pmap_enter()
does not flush the tlb at VA. TLB still contains the invalid pte.
System resumes operation, but invalid tlb entry for VA is still
in the tlb. Bewm.
Personally speaking I think we should simply invalidate the
tlb at VA whenever we modify a pte, no matter what the original
contents of that pte was. For both 3.x and 4.x.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002250051.QAA43750>