From owner-freebsd-current Thu Feb 24 13: 6: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D023C37B9C0 for ; Thu, 24 Feb 2000 13:06:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA42378; Thu, 24 Feb 2000 13:05:58 -0800 (PST) (envelope-from dillon) Date: Thu, 24 Feb 2000 13:05:58 -0800 (PST) From: Matthew Dillon Message-Id: <200002242105.NAA42378@apollo.backplane.com> To: Bruce Evans Cc: David Gilbert , freebsd-current@FreeBSD.ORG Subject: Re: Wierd AMD panics caused by VMWare? References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :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 Ok, lets narrow it down - if we can panic the kernel with a dup2() then the problem should reside in the fdalloc() chain somewhere. fdalloc() uses MALLOC(), bcopy, and bzero to reallocate the chain. Due to the way fdalloc() works, we are multiplying nfiles by 2 and reallocating the array in a loop until we reach the file descriptor number we want. (BTW, this will seriously fragment the MALLOC pool!). We also are MALLOC()ing space that is oddly sized, due to OFILESDIZE being (sizeof(struct file *) + sizeof(char)). Well, this tells me there is a fairly good chance that we are hitting a bug in the kernel MALLOC somewhere related to the kernel pmap, or a bug in fdalloc(). I'll take a close look at both. That is where I recommend we start. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message