From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 13:58:54 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 6AE6216A4CE for ; Mon, 19 Jul 2004 13:58:54 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1438543D46 for ; Mon, 19 Jul 2004 13:58:54 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i6JDwNGo049871; Mon, 19 Jul 2004 09:58:23 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i6JDwNaS049868; Mon, 19 Jul 2004 09:58:23 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 19 Jul 2004 09:58:23 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Willem Jan Withagen In-Reply-To: <11e601c46d5c$d9db1910$471b3dd4@digiware.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: panic: Duplicate free of item 0xffffff005c4a8600 fromzone0xffffff007fed4780(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: Mon, 19 Jul 2004 13:58:54 -0000 On Mon, 19 Jul 2004, Willem Jan Withagen wrote: > > I'll starts some more tests before I'm of to bed. > > This mornings result: > ==== > System call getdirentries returning with the following locks held: > exclusive sleep mutex bdone lock r = 0 (0xffffffff805fd080) locked @ /home2/src/ > sys/kern/vfs_bio.c:3767 > panic: witness_warn > cpuid = 0; > KDB: stack backtrace: > kdspin lock sched lock held by 0xffffff007b6cc940 for > 5 seconds > panic: spin lock held too long > cpuid = 0; > KDB: enter: panic > ==== > > But no way to get into the debugger. Does not look like it is much > network related??? Doesn't look very network related, although it could be that increased concurrency and lack of waiting on Giant open up a race of some sort. Can you confirm "options DDB" and "options KDB" are both in your kernel config? You may want to consider commenting out "#define PREEMPTION" in the copy of params.h for the architecture you're running on and see if that helps. Won't help interrupt processing latency, but probably won't hurt server throughput, and your box is a server box so it might be worth trying. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research