Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Jan 2011 14:37:55 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-net@freebsd.org
Cc:        Przemyslaw Frasunek <przemyslaw@frasunek.com>, Eugene Grosbein <egrosbein@rdtc.ru>, Mike Tancsa <mike@sentex.net>
Subject:   Re: panic: bufwrite: buffer is not busy???
Message-ID:  <201101141437.55421.jhb@freebsd.org>
In-Reply-To: <4D309983.70709@rdtc.ru>
References:  <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, January 14, 2011 1:44:19 pm Eugene Grosbein wrote:
> On 14.01.2011 18:46, Mike Tancsa wrote:
> 
> >> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE
> >> concurrent sessions. Routers are based on Intel SR1630GP hardware platforms and
> >> runs FreeBSD 7.3-RELEASE.
> >>
> >> I'm experiencing stability issues related to Netgraph. None of above routers can
> >> survive more than 20-30 days of uptime under typical load. There are different
> >> flavors of kernel panics, but all are somehow related to netgraph. Typical
> >> backtraces follow
> > 
> > I also have stability issues on RELENG_8.
> > 
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=153497
> 
> And for one of my servers (8.2-PRERELEASE/amd64 with 4GB RAM) I just cannot obtain crashdump,
> it cannot finish to write it. For example, it happened an hour ago:
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 04
> fault virtual address   = 0x200000040
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x20:0xffffffff803cc979

Assuming your kernel is built with debug symbols (which is the default), one
thing you can do to aid in debugging is this:

gdb /boot/kernel/kernel
(gdb) l *0xffffffff803cc979

Where the 0xfff<blah> bit is the part of the 'instruction pointer' value
above after the colon (:) and then send the output of that in your e-mail to
the list.  This allows us to the source line at which the fault occurred.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101141437.55421.jhb>