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