From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 16 11:52:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CA321065670 for ; Wed, 16 Dec 2009 11:52:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 35A7F8FC15 for ; Wed, 16 Dec 2009 11:52:38 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C867946B23; Wed, 16 Dec 2009 06:52:37 -0500 (EST) Date: Wed, 16 Dec 2009 11:52:37 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Linda Messerschmidt In-Reply-To: <237c27100912151140o1b227bb1pdaa65f5aee13ab5b@mail.gmail.com> Message-ID: References: <237c27100912151140o1b227bb1pdaa65f5aee13ab5b@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: 8.0-RELEASE-p1 Panic "panic: sbdrop" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 11:52:38 -0000 On Tue, 15 Dec 2009, Linda Messerschmidt wrote: > This is a new one on me: Hi Linda-- Unfortunately, this has historically been a tricky panic to debug, as it's associated with a sanity check that picks up kernel memory corruption that may have occurred at a much earlier time. Without a crashdump, we won't get much further. However, let's see what we can do, perhaps trying to find some common configuration element with another past report of the same diagnostic. FYI, typically this panic occurs as a result of a concurrency bug in a device driver, although it can be a symptom of a more general network stack bug. Could you tell us a bit more about the network configuration -- especially, are you using any tunneling software (such as ipsec), netgraph, or other less commonly used network features? Are you using accept filters? Robert N M Watson Computer Laboratory University of Cambridge > > panic: sbdrop > cpuid = 3 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x182 > sbdrop_internal() at sbdrop_internal+0x323 > soisdisconnected() at soisdisconnected+0xbe > tcp_close() at tcp_close+0x45 > tcp_do_segment() at tcp_do_segment+0x122f > tcp_input() at tcp_input+0xc92 > ip_input() at ip_input+0xac > netisr_dispatch_src() at netisr_dispatch_src+0x7e > ether_demux() at ether_demux+0x15d > ether_input() at ether_input+0x17b > em_rxeof() at em_rxeof+0x287 > em_handle_rxtx() at em_handle_rxtx+0x2f > taskqueue_run() at taskqueue_run+0x93 > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8000117d30, rbp = 0 --- > > This machine runs squid as a reverse proxy, and this has happened a > couple of times now in the past day. > > Unfortunately it's a production machine, so we'll have to go back to > 7.2. I can probably leave it as-is for 24 hours or so if anybody > wants me to check something, but it doesn't have a dump or a debug > kernel and I unfortunately can't put it back in production to provoke > another crash. :( But I wanted to at least report this before we > did in case it's useful to anyone. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >