Date: Mon, 17 Jan 2011 13:02:43 -0800 From: Garrett Cooper <gcooper@FreeBSD.org> To: Sergey Kandaurov <pluknet@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Known LoR when taking bringing up bge(4) after system in multiuser? Message-ID: <AANLkTi=mW0yH60VyDv-HaHbE6hytumdo%2BEMR8OEA2wof@mail.gmail.com> In-Reply-To: <AANLkTik0CR75c-=PWA3RmYP1nxZRJKd7H0B3_Lsn3o1m@mail.gmail.com> References: <7d6fde3d1002191625m4d0d160dq2dc24f124aa38d0e@mail.gmail.com> <AANLkTik0CR75c-=PWA3RmYP1nxZRJKd7H0B3_Lsn3o1m@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 17, 2011 at 7:44 AM, Sergey Kandaurov <pluknet@gmail.com> wrote=
:
> On 20 February 2010 03:25, Garrett Cooper <yanefbsd@gmail.com> wrote:
>> Hi,
>> =A0 =A0I came across the following LoR:
>>
>> lock order reversal:
>> =A01st 0xc56aae04 if_afdata (if_afdata) @
>> /usr/home/garrcoop/ipcvs/freebsd/src/sys/net/if_llatbl.c:130
>> =A02nd 0xc58a1d80 radix node head (radix node head) @
>> /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+0x3=
f0
>> 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+0=
x107
>> intr_event_execute_handlers(c55717f8,c5576a00,c0c61560,533,c5576a70,...)
>> at intr_event_execute_handlers+0x10f
>> ithread_loop(c56b26c0,c5264d38,c0c612a1,343,c55717f8,...) at ithread_loo=
p+0x98
>> fork_exit(c084923c,c56b26c0,c5264d38) at fork_exit+0xb8
>> fork_trampoline() at fork_trampoline+0x8
>> --- trap 0, eip =3D 0, esp =3D 0xc5264d70, ebp =3D 0 ---
>>
>> =A0 =A0when I did the following steps [once]:
>>
>> echo "ifconfig_bge0=3D\"DHCP\"" >> /etc/rc.conf
>> /etc/rc.d/netif start
>>
>> =A0 =A0using srcs from cvs pulled in the last 2 days or so...
>> =A0 =A0I'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 =A0obytes
> rder reversal:
> =A01st 0xfffffe00184413c0 if_afdata (if_afdata) @ /usr/src/sys/net/if_lla=
tbl.c:151
> =A02nd 0xfffffe0018ee32f8 radix node head (radix node head) @
> /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 =3D 0x80095334c, rsp =3D
> 0x7ffffffed608, rbp =3D 0x40 ---
> 64 bytes from 8.8.8.8: icmp_seq=3D0 ttl=3D56 time=3D1332.205 ms
> 64 bytes from 8.8.8.8: icmp_seq=3D0 ttl=3D56 time=3D1332.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,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=mW0yH60VyDv-HaHbE6hytumdo%2BEMR8OEA2wof>