On Mon, Jan 17, 2011 at 7:44 AM, Sergey Kandaurov <pluknet_at_gmail.com> wrote: > On 20 February 2010 03:25, Garrett Cooper <yanefbsd_at_gmail.com> wrote: >> Hi, >> I came across the following LoR: >> >> lock order reversal: >> 1st 0xc56aae04 if_afdata (if_afdata) _at_ >> /usr/home/garrcoop/ipcvs/freebsd/src/sys/net/if_llatbl.c:130 >> 2nd 0xc58a1d80 radix node head (radix node head) _at_ >> /usr/home/garrcoop/ipcvs/freebsd/src/sys/net/route.c:360 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0c6993e,c5264828,c08b173f,c08a2f35,c0c6c9d1,...) >> at db_trace_self_wrapper+0x26 >> kdb_backtrace(c08a2f35,c0c6c9d1,c5530758,c552b680,c5264884,...) at >> kdb_backtrace+0x29 >> _witness_debugger(c0c6c9d1,c58a1d80,c0c6cacb,c552b680,c0c77940,...) at >> _witness_debugger+0x1e >> witness_checkorder(c58a1d80,1,c0c77940,168,0,...) at witness_checkorder+0x818 >> _rw_rlock(c58a1d80,c0c77940,168,c568d2e4,1,...) at _rw_rlock+0x9c >> rtalloc1_fib(c5264a60,0,0,0,c526493c,...) at rtalloc1_fib+0x82 >> rtalloc1(c5264a60,0,0,1,0,...) at rtalloc1+0x27 >> in_lltable_rtcheck(c56aac00,a000,c5264a60,576,c0c7691c,...) at >> in_lltable_rtcheck+0x3e >> in_lltable_lookup(c58a1b00,a000,c5264a60,c0913e33,52098000,...) at >> in_lltable_lookup+0xc3 >> llentry_update(c52649f0,c58a1b00,c5264a60,c56aac00,c552c4b8,...) at >> llentry_update+0xa3 >> flowtable_lookup(c5739400,c5b27700,c5264a58,0,3,...) at flowtable_lookup+0x437 >> ip_output(c5b27700,0,0,0,0,...) at ip_output+0xf8 >> icmp_reflect(1,10,0,c552c6c0,c552bf70,...) at icmp_reflect+0x5cc >> icmp_input(c5b27700,14,c568d240,c0dafc80,c568d240,...) at icmp_input+0x3f0 >> ip_input(c5b27700,c5264bcc,c07235f4,c0dafc80,0,...) at ip_input+0x619 >> netisr_dispatch_src(1,0,c5b27700,c5264c04,c091c349,...) at >> netisr_dispatch_src+0xcb >> netisr_dispatch(1,c5b27700,c56aac00,c56aac00,c5b74002,...) at >> netisr_dispatch+0x20 >> ether_demux(c56aac00,c5b27700,3,0,3) at ether_demux+0x193 >> ether_input(c56aac00,c5b27700,c0c250e6,d41,c56b7008,...) at ether_input+0x355 >> bge_rxeof(c56b7008,0,c0c250e6,e13,c56b7008,...) at bge_rxeof+0x2b9 >> bge_intr(c56b7000,c5264cc8,c085f65d,c0dc8880,c5576a38,...) at bge_intr+0x107 >> intr_event_execute_handlers(c55717f8,c5576a00,c0c61560,533,c5576a70,...) >> at intr_event_execute_handlers+0x10f >> ithread_loop(c56b26c0,c5264d38,c0c612a1,343,c55717f8,...) at ithread_loop+0x98 >> fork_exit(c084923c,c56b26c0,c5264d38) at fork_exit+0xb8 >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0, eip = 0, esp = 0xc5264d70, ebp = 0 --- >> >> when I did the following steps [once]: >> >> echo "ifconfig_bge0=\"DHCP\"" >> /etc/rc.conf >> /etc/rc.d/netif start >> >> using srcs from cvs pulled in the last 2 days or so... >> I'll gladly provide more details when requested. > > I faced a similar LOR when running ping. > Looks like it's not bge related, but comes from arpv2 and/or flowtable. > > # ping 8.8.8.8 > loPING 8.8.8.8 (8.ck8.8.8): 56 data obytes > rder reversal: > 1st 0xfffffe00184413c0 if_afdata (if_afdata) _at_ /usr/src/sys/net/if_llatbl.c:151 > 2nd 0xfffffe0018ee32f8 radix node head (radix node head) _at_ > /usr/src/sys/net/route.c:362 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x807 > _rw_rlock() at _rw_rlock+0x6d > rtalloc1_fib() at rtalloc1_fib+0x10b > in_lltable_rtcheck() at in_lltable_rtcheck+0x35 > in_lltable_lookup() at in_lltable_lookup+0xbb > llentry_update() at llentry_update+0x19e > flowtable_lookup() at flowtable_lookup+0x6f6 > flowtable_lookup_mbuf() at flowtable_lookup_mbuf+0x3c6 > ip_output() at ip_output+0xa9c > rip_output() at rip_output+0x246 > sosend_generic() at sosend_generic+0x347 > kern_sendit() at kern_sendit+0x1b5 > sendit() at sendit+0xdc > sendto() at sendto+0x4d > syscallenter() at syscallenter+0x1aa > syscall() at syscall+0x4c > Xfast_syscall() at Xfast_syscall+0xe2 > --- syscall (133, FreeBSD ELF64, sendto), rip = 0x80095334c, rsp = > 0x7ffffffed608, rbp = 0x40 --- > 64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=1332.205 ms > 64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=1332.274 ms (DUP!) I'll see if I can quickly reproduce that in-house with our bge-enabled machines on Tuesday with a bleeding edge CURRENT image if I have the time. Thanks, -GarrettReceived on Mon Jan 17 2011 - 20:03:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:10 UTC