Date: Thu, 24 Feb 2000 13:05:58 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Bruce Evans <bde@zeta.org.au> Cc: David Gilbert <dgilbert@velocet.ca>, freebsd-current@FreeBSD.ORG Subject: Re: Wierd AMD panics caused by VMWare? Message-ID: <200002242105.NAA42378@apollo.backplane.com> References: <Pine.BSF.4.21.0002250740030.7691-100000@alphplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> :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
<dillon@backplane.com>
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?200002242105.NAA42378>