Date: Tue, 01 Feb 2011 11:53:36 +0600 From: Eugene Grosbein <egrosbein@rdtc.ru> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: panic: bufwrite: buffer is not busy??? Message-ID: <4D479FE0.70809@rdtc.ru> In-Reply-To: <201101311146.43119.jhb@freebsd.org> References: <4D3011DB.9050900@frasunek.com> <201101141437.55421.jhb@freebsd.org> <4D46575A.802@rdtc.ru> <201101311146.43119.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31.01.2011 22:46, John Baldwin wrote:
>># 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);
>
> Hmmm. I think you might have a hardware problem. Notice the fault address,
> it is 0x200000030. Can you do 'x/i <instruction pointer>'?
(gdb) x/i 0xffffffff803c1315
0xffffffff803c1315 <ng_address_hook+37>: testb $0x1,0x28(%rdx)
(gdb) x/i *0xffffffff803c1315
0x12842f6: Cannot access memory at address 0x12842f6
> I suspect it is
> doing a memory access from that has a constant offset of 0x30, in which case
> the original pointer was 0x200000000, meaning it would be NULL except it has a
> single-bit error. That would likely be caused by a hardware issue such as
> failing RAM, etc.
This is SuperMicro server with ECC RAM. I've already tested it with memtest86+
during long time, no memory problems found.
Eugene Grosbein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D479FE0.70809>