Date: Wed, 16 Dec 2009 11:52:37 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Linda Messerschmidt <linda.messerschmidt@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: 8.0-RELEASE-p1 Panic "panic: sbdrop" Message-ID: <alpine.BSF.2.00.0912161149570.36302@fledge.watson.org> In-Reply-To: <237c27100912151140o1b227bb1pdaa65f5aee13ab5b@mail.gmail.com> References: <237c27100912151140o1b227bb1pdaa65f5aee13ab5b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0912161149570.36302>