Re: list of wellknown LORs ?

On Wednesday 19 November 2003 02:12 pm, Bjoern A. Zeeb wrote:
> Hi,
>
> is anybody involved in fixing perhaps going to put up a site with all the
> wellknown LORs and perhaps a state (like: work in progress (by ...),
> ingorable, ...).
>
> I have seen three the last minutes where at least two seem to be known
> when grepping through my mailing lists archives and one of those two
> has a promised fix with upcoming chnages...
>
> wouldn't it be good to have one resource for overall status and may
> reduce noice ?
>
>
> ----------------------------------------
> lock order reversal
>  1st 0xc3a23090 rtentry (rtentry) _at_
> HEAD/compile-20031119-1814/sys/net/rtsock.c:389 2nd 0xc396587c radix node
> head (radix node head) _at_ HEAD/compile-20031119-1814/sys/net/route.c:1114
>
> STATE:
> "go away with forthcoming changes" (sam, current_at_ 2003-11-xx)
>

Correct, this and at least one other in the routing table should go away with 
changes about to be committed.

>
> ----------------------------------------
> lock order reversal
>  1st 0xc3a368f8 inp (inp) _at_
> HEAD/compile-20031119-1814/sys/netinet/tcp_usrreq.c:363 2nd 0xc063b4ac div
> (div) _at_ HEAD/compile-20031119-1814/sys/netinet/ip_divert.c:238
>
> STATE:
> known:
> http://lists.freebsd.org/pipermail/freebsd-current/2003-August/008743.html
> + fix available ?
>
>
> ----------------------------------------
> lock order reversal
>  1st 0xc063b580 IPFW dynamic rules (IPFW dynamic rules) _at_
> HEAD/compile-20031119-1814/sys/netinet/ip_fw2.c:2934 2nd 0xc063b548 IPFW
> static rules (IPFW static rules) _at_
> HEAD/compile-20031119-1814/sys/netinet/ip_fw2.c:1586 Stack backtrace:
> backtrace(1,0,ffffffff,c06155f0,c0615618) at backtrace+0x12
> witness_lock(c063b548,8,c05cf951,632,c063b548) at witness_lock+0x534
> _mtx_lock_flags(c063b548,0,c05cf951,632) at _mtx_lock_flags+0x7f
> ipfw_chk(c9b4ac0c,0,c9b4abb4,c04ba25c,c0615870) at ipfw_chk+0x28e
> ip_output(c2f8f600,0,0,0,0) at ip_output+0x9f3
> send_pkt(c3b1a91c,e2e48f46,1a0e0dd3,2,e) at send_pkt+0x13c
> ipfw_tick(0) at ipfw_tick+0xae
> softclock(0) at softclock+0x176
> ithread_loop(c2f6d580,c9b4ad48,c2f6d580,c048ab00,0) at ithread_loop+0x12b
> fork_exit(c048ab00,c2f6d580,c9b4ad48) at fork_exit+0x90
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xc9b4ad7c, ebp = 0 ---

There are part of a set of "middleware" LOR's that also have been waiting on 
the routing table changes.  Once those changes are committed I will resolve 
them.

	Sam