Date: Wed, 03 Apr 2002 19:29:22 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Will Froning <wfroning@angui.sh> Cc: hackers@freebsd.org Subject: Re: Fatal trap 12: page fault while in kernel mode Message-ID: <3CABC892.E3E4517E@mindspring.com> References: <20020403181854.I42720-100000@angui.sh>
next in thread | previous in thread | raw e-mail | index | archive | help
Will Froning wrote:
> #12 0xc014f61d in panic ()
> #13 0xc025c02f in trap_fatal ()
> #14 0xc025bcdd in trap_pfault ()
> #15 0xc025b883 in trap ()
> #16 0xc0152220 in tsleep ()
> #17 0xc016abfe in m_clalloc_wait ()
The tsleep tried to reference a page that wasn't there. This
supposedly can't happen. Here is the tsleep:
caddr_t
m_clalloc_wait(void)
{
...
/* Sleep until something's available or until we expire. */
m_clalloc_wid++;
if ((tsleep(&m_clalloc_wid, PVM, "mclalc", mbuf_wait)) ==
EWOULDBLOCK)
m_clalloc_wid--;
The m_clalloc_wid is a global variable, so it's not swapped out.
The mbuf_wait is a tunable; it defaults to 32. You might want to
try tuning this higher... making it wait longer... or setting it
to 0 -- making it wait forever. This would workaround, or eliminate
you problem.
That the thing panics implies to me that the page that it references
got swapped out from under it (or freed).
The call happens when you are in an extremely low memory condition,
out of mbufs, and then you try to allocate more. The wakeup on
the free does not guarantee that you will get the resource, in
a resource-staved state. This would be much better served by a
wakeup_one() instead of a wakeup(), wakeup_one() will not keep the
process being awakened from losing the race for the allocation, if
someone else comes in for the allocation at the same time, through
another path (e.g. handing a network card interrupt allocation for
an mbuf).
The best answer is probably to say: "add mbufs". This will keep
you from hitting the starvation problem here. Fixing the other
issues are deeper problems (the second panic is also related to
memory, that time for a lock).
Other than that, you will have to do some tracking down, if
you really want it to fail gracefully... one option is make
m_clalloc_wait actually frigging wait. It was an incredible
error when "_wait" no longer meant "wait", but instead turned
into "wait for a bit, then fail spectacularly".
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CABC892.E3E4517E>