The copy of isc-dhcpd running causes this bug to occur with the routing table in an unknown state with a call to sendto(0.0.0.0). All I really know is that the bug is the lock for the rtentry being recursed on because it has no rt_gwroute, yet has flags set to exactly RTF_UP|RTF_GATEWAY, and gets returned again by rtalloc1(). You can find it in rt_check() easily enough if you follow the RTF_UP, RTF_GATEWAY path downward. panic(c0663eb9,c0669491,b6,c0669491,50c) at panic+0xd5 witness_lock(c1878264,8,c0669491,50c,c1878200) at witness_lock+0x3b3 _mtx_lock_flags(c1878264,0,c0669488,50c,32) at _mtx_lock_flags+0xba rt_check(c634ba20,c634ba68,c1650650,c04e5440,c1870000) at rt_check+0x19a ether_output(c1626000,c0e43700,c1650650,c1878200,c051642a) at ether_output+0x60 ip_output(c0e43700,0,0,20,0) at ip_output+0xdb1 udp_output(c16a84ec,c0e43700,c0df9820,0,c15c3780) at udp_output+0x408 udp_send(c16a4690,0,c0e43700,c0df9820,0) at udp_send+0xb7 sosend(c16a4690,c0df9820,c634bc4c,c0e43700,0) at sosend+0x44d kern_sendit(c15c3780,5,c634bcc4,0,0) at kern_sendit+0x17c sendit(c15c3780,5,c634bcc4,0,806a03c) at sendit+0x16e sendto(c15c3780,c634bd14,c0677f0f,3ee,6) at sendto+0x5b syscall(bfbf002f,2f,bfbf002f,bfbfeba1,bfbfed60) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (133, FreeBSD ELF32, sendto), eip = 0x280f468f, esp = 0xbfbfe6fc, ebp = 0xbfbfe748 --- Also of note is that the rt_setgate() function also in net/route.c includes a clause to return EDQUOT if something similar occurs. As it is, I have no idea of that one can occur, or much else in the matter. Anyone that might know anything about this I'd appreciate help from. Thanks! -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green_at_FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\Received on Tue Dec 09 2003 - 14:05:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:33 UTC