8.0-RELEASE-p1 Panic "panic: sbdrop"

[Robert Watson]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>