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>