Re: Experiencing hangs on SMP box with no console messages given for clues. Details inside.

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Sun, 18 Mar 2007 15:50:01 +0100 (BST)
On Sun, 18 Mar 2007, Bjoern A. Zeeb wrote:

> On Sun, 11 Mar 2007, Tillman Hodgson wrote:
>
>> On Sat, Mar 10, 2007 at 10:40:33PM -0600, Tillman Hodgson wrote:
>>> Shouldn't take more than a day or two to get the info requested in
>>> 11.9.
>> 
>> As it turns out, a few hours.
>> 
>> After capturing the information below I ran `panic`. While booting, the 
>> following lock messages came up -- I thought it might be related so I'll 
>> post it here:

If using uid/gid firewall rules, make sure to read the pertinent man pages 
regarding setting debug.mpsafenet=0 in loader.conf to avoid deadlocks.  This 
is only a workaround for the issue, and when debug.mpsafenet is removed, this 
workaround will no longer be available.  The authors/maintainers of the 
various firewall packages need to correct these problems or the lock order 
reversals (and associated deadlocks) will persist.

Robert N M Watson
Computer Laboratory
University of Cambridge

>> 
>> ...
>> Starting spamd.
>> lock order reversal:
>> 1st 0xc44d8c44 pf task mtx (pf task mtx) _at_ 
>> /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6414
>> 2nd 0xc0a9df6c tcp (tcp) _at_ 
>> /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:2760
>> KDB: stack backtrace:
>> db_trace_self_wrapper(c094da94) at db_trace_self_wrapper+0x25
>> kdb_backtrace(0,ffffffff,c0a5d7d8,c0a5f330,c09f6c04,...) at 
>> kdb_backtrace+0x29
>> witness_checkorder(c0a9df6c,9,c44d5e24,ac8) at witness_checkorder+0x586
>> _mtx_lock_flags(c0a9df6c,0,c44d5e24,ac8,c0a9df6c,...) at 
>> _mtx_lock_flags+0x84
>> pf_socket_lookup(e466da84,e466da88,1,e466db40,0,...) at 
>> pf_socket_lookup+0x1d3
>> pf_test_tcp(e466daf0,e466dae8,1,c4505d00,c4467700,...) at 
>> pf_test_tcp+0x11e6
>> pf_test(1,c4098800,e466dbdc,0,0,...) at pf_test+0xae3
>> pf_check_in(0,e466dbdc,c4098800,1,0) at pf_check_in+0x37
>> pfil_run_hooks(c0a9db40,e466dc2c,c4098800,1,0) at pfil_run_hooks+0x7f
>> ip_input(c4467700) at ip_input+0x232
>> netisr_dispatch(2,c4467700,0,c4098800,c44a0800,...) at netisr_dispatch+0x58
>> ether_demux(c4098800,c4467700,c4037000,c44a1002,e466dca0,...) at 
>> ether_demux+0x28a
>> ether_input(c4098800,c4467700,c4037014,0,c092325d,...) at ether_input+0x202
>> fxp_intr_body(c4037000,c4098800,40,ffffffff) at fxp_intr_body+0x1a0
>> fxp_intr(c4037000) at fxp_intr+0x95
>> ithread_execute_handlers(c40a0240,c3f46900) at 
>> ithread_execute_handlers+0x11e
>> ithread_loop(c40433a0,e466dd38) at ithread_loop+0x67
>> fork_exit(c06adf00,c40433a0,e466dd38) at fork_exit+0xac
>> fork_trampoline() at fork_trampoline+0x8
>> --- trap 0, eip = 0, esp = 0xe466dd70, ebp = 0 ---
>> Starting courier_authdaemond.
>> ...
>
> The above looks like LOR #17 or #191 just with a direct dispatch.
> 	http://sources.zabbadoz.net/freebsd/lor/191.html
>
> I added the traceback there and added a link to this thread.
>
> I can see that you at least recompiled your kernel lately - do
> you have up-to-date sources or should I mark the LOR as problematic
> again?
> :a
>
>
>
> -- 
> Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Sun Mar 18 2007 - 13:50:04 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:06 UTC