A few days ago I posted to -stable about a LOR observed on our 5.4-based tree with SMP, DEVICE_POLLING and fxp: http://lists.freebsd.org/pipermail/freebsd-stable/2005-May/015376.html Contrary to my earlier assertion, em does not have a problem. We do have a fair amount of local diffs, so I've now confirmed this is easily reproduced on unmodified -CURRENT as of 05/28. My config file has options SMP options DEVICE_POLLING device fxp (full config file at http://www.maste.org/~ed/sv/STOCK.1 ) lock order reversal 1st 0xa0783860 Giant (Giant) _at_ /d2/emaste/cvs_head/src/sys/kern/kern_poll.c:332 2nd 0xa23e22a0 fxp0 (network driver) _at_ /d2/emaste/cvs_head/src/sys/dev/fxp/if_fxp.c:1473 KDB: stack backtrace: kdb_backtrace(0,ffffffff,a07a6168,a07a4750,a0759160) at 0xa0585789 = kdb_backtrace+0x29 witness_checkorder(a23e22a0,9,a070a173,5c1) at 0xa058f74c = witness_checkorder+0x55c _mtx_lock_flags(a23e22a0,0,a070a173,5c1) at 0xa05652f8 = _mtx_lock_flags+0x60 fxp_poll(a23e2000,1,5) at 0xa04fa001 = fxp_poll+0x29 netisr_poll(0) at 0xa0567070 = netisr_poll+0x188 swi_net(0) at 0xa05d9041 = swi_net+0x81 ithread_loop(a2309000,c5d8fd38,a2309000,a055aba8,0) at 0xa055acc8 = ithread_loop+0x120 fork_exit(a055aba8,a2309000,c5d8fd38) at 0xa055a0f0 = fork_exit+0xa0 fork_trampoline() at 0xa06ad31c = fork_trampoline+0x8 The ether_poll_deregister in fxp_stop() looks to be the culprit. -- Ed Maste, Sandvine IncorporatedReceived on Mon May 30 2005 - 11:44:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:35 UTC