Date: Mon, 31 Jan 2011 00:20:18 -0800 From: Julian Elischer <julian@freebsd.org> To: Eugene Grosbein <egrosbein@rdtc.ru> Cc: freebsd-net@freebsd.org, Przemyslaw Frasunek <przemyslaw@frasunek.com>, John Baldwin <jhb@freebsd.org>, Mike Tancsa <mike@sentex.net> Subject: Re: panic: bufwrite: buffer is not busy??? Message-ID: <4D4670C2.4050500@freebsd.org> In-Reply-To: <4D46575A.802@rdtc.ru> References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/30/11 10:31 PM, Eugene Grosbein wrote: > On 15.01.2011 01:37, John Baldwin wrote: >> 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. >> > Yesterday I've got another kernel panic of this kind with RELENG_8 updated 20 January > and it still could not finish writing of crashdump: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 02 > fault virtual address = 0x200000030 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff803c1315 > stack pointer = 0x28:0xffffff8000130780 > frame pointer = 0x28:0xffffff80001307a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq259: em1:rx 0) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 19h41m8s > Dumping 4087 MB (3 chunks) > chunk 0: 1MB (150 pages) ... ok > chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? > cpuid = 1 > Uptime: 19h41m9s > Automatic reboot in 15 seconds - press a key on the console to abort > > This time I have all debug symbols handy: > > > # gdb kernel > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > (gdb) l *0xffffffff803c1315 > 0xffffffff803c1315 is in ng_address_hook (/home/src/sys/netgraph/ng_base.c:3504). > 3499 * Quick sanity check.. > 3500 * Since a hook holds a reference on it's node, once we know > 3501 * that the peer is still connected (even if invalid,) we know > 3502 * that the peer node is present, though maybe invalid. > 3503 */ > 3504 if ((hook == NULL) || > 3505 NG_HOOK_NOT_VALID(hook) || > 3506 NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) || > 3507 NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) { > 3508 NG_FREE_ITEM(item); replace with: 3504 if ((hook == NULL) || 3505 NG_HOOK_NOT_VALID(hook) || ((peer = NG_HOOK_PEER(hook)) == NULL) || 3506 NG_HOOK_NOT_VALID(peer) || ((peernode = NG_PEER_NODE(hook)) == NULL) || 3507 NG_NODE_NOT_VALID(peernode)) { if (peer) kassert((peernode != NULL), ("peer node NULL wile peer hook exists")); 3508 NG_FREE_ITEM(item); > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D4670C2.4050500>