From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 15:30:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D4F916A4CE; Sun, 18 Jul 2004 15:30:46 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC22A43D48; Sun, 18 Jul 2004 15:30:45 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with SMTP id i6IFT0sD053910; Sun, 18 Jul 2004 17:29:00 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <0f7001c46cdb$0b23cdf0$471b3dd4@digiware.nl> From: "Willem Jan Withagen" To: "Robert Watson" References: Date: Sun, 18 Jul 2004 17:22:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: current@freebsd.org Subject: Re: panic: Duplicate free of item 0xffffff005c4a8600 from zone 0xffffff007fed4780(Mbuf) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2004 15:30:46 -0000 From: "Robert Watson" > On Sun, 18 Jul 2004, Willem Jan Withagen wrote: > > > Started running with debug.mpsafe=1. Not shure if it has anything to do > > with it.... > > It might well do, but here are some things to try: > > - See if you can reproduce this with your exact some configuration in a > few runs. If you can, then we should try some other configurations. Yup, just got almost the same one.... It took a little longer, but perhaps cause I did not untar the port I'm trying to test on amd64. Slab at 0xffffff006624ffa0, freei 29 = 0. panic: Duplicate free of item 0xffffff006624fcb0 from zone 0xffffff007fed4180(Fi les) cpuid = 1; KDB: stack backtrace: kdb_backtrace() at kdb_backtrace+0x34 panic() at panic+0x1d2 uma_dbg_free() at uma_dbg_free+0x112 uma_zfree_arg() at uma_zfree_arg+0x10a ffree() at ffree+0x8e fdrop_locked() at fdrop_locked+0xce fdrop() at fdrop+0x32 getdirentries() at getdirentries+0x2fc syscall() at syscall+0x2fa Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x2006a2204, rsp = 0x7fff ffffe758, rbp = 0x7fffffffe780 --- KDB: enter: panic [thread 100132] Stopped at kdb_enter+0x2e: nop I'll try one more time. > - Try it with debug.mpsafenet=0 and see if the problem "goes away" for a > few runs. I'll disable mpsafenet for the then next 2 runs... > - Try compiling IPv6 out of your kernel -- this will turn on the inpcb > locking assertions, which are compiled out by default because IPv4 and > IPv6 share the same underlying pcb code and IPv6 does not yet lock that > correctly in CVS. I have patches that do quite a bit of that in > Perforce, and sent out an e-mail yesterday to the KAME folk to talk > about merging strategies. > > - If this is a reproduceable problem, could you try disabling SACK and see > if it changes at all? For future steps. > I'll do some review of the TCP reassembly and queue bits, it could well be > that we're missing some locking here. Nicely configured system, btw. :-) I needed a "big" tax/profit reduction in my company.... Why not spend it on a nice toy. > BTW, I noticed that there are some bge0 warnings at the end of the dmesg > -- is that indicative of some other problem with the driver on the system, > and/or is bge0 used in your active configuration? Thanks for the nice > bundling of config information, btw -- it answered a number of my > questions up front quite nicely. Thanx, I think that is the simpelest way for me to keep this easy available. I'm considering updating this info with a /usr/local/etc/rc.d script... Just timestamp it, and autoremove things older than a few versions. The bge0 device is the active one.... It plugs into a noname switch, and it could be that line-negotiation is not fast enough to be ready for the bge0 to timeout on handshaking to get the line-mode. The watchdog reset gets things straightend out. Not it is a onboard Broadcom BCM5705, which has perhaps some flaws (as was claimed some time ago???) We're up again, but I'll remove the de0 card first. To be continued, --WjW