From owner-freebsd-current Thu Feb 24 12:51:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 7EF0B37B891 for ; Thu, 24 Feb 2000 12:51:06 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (qmail 9529 invoked from network); 24 Feb 2000 20:50:53 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 24 Feb 2000 20:50:53 -0000 Date: Fri, 25 Feb 2000 07:50:49 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Matthew Dillon Cc: David Gilbert , freebsd-current@FreeBSD.ORG Subject: Re: Wierd AMD panics caused by VMWare? In-Reply-To: <200002232043.MAA31642@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 23 Feb 2000, Matthew Dillon wrote: [I wrote] > :See PR 16568. pmap_remove_all() doesn't flush the TLB properly in > :FreeBSD-3.x on i386's. Somehow this doesn't cause many problems, but > :it fairly reliably breaks the free() in fdfree() when there was a file > :descriptor larger than about 1000 (this gives a free() of more than > :MAXALLOCSAVE = 2 pages) when there is a lot of fork() activity. > Ahh. I presume you will commit this patch now that Bjoern has > confirmed that it works? Not until the reason that it works is understood. > I don't know why an unconditional invltlb() didn't work either, > it should have. Maybe the __asm macro is being optimized out. I verified that the unconditional invtlb() doesn't work. Better yet, replacing the invltlb_1pg() in the loop doesn't work. I think this means that we've changed the page tables too early for a page elsewhere. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message