Date: Sat, 26 Feb 2000 08:40:41 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: David Gilbert <dgilbert@velocet.ca>, freebsd-current@FreeBSD.ORG Subject: Re: Patch to try (was Re: Wierd AMD panics caused by VMWare?) Message-ID: <Pine.BSF.4.21.0002260757010.9581-100000@alphplex.bde.org> In-Reply-To: <200002250033.QAA43662@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?Pine.BSF.4.21.0002260757010.9581-100000>