Date: Sun, 26 Nov 2006 17:43:45 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Max Laier <max@love2party.net> Cc: Nicolae Namolovan <adrenalinup@gmail.com>, freebsd-net@freebsd.org Subject: Re: ping -f panic [Re: Marvell Yukon 88E8056 FreeBsd Drivers] Message-ID: <20061126165353.Y47830@delplex.bde.org> In-Reply-To: <200611260331.28847.max@love2party.net> References: <f027bef40611240533k453e90dfve6f662794bba3b84@mail.gmail.com> <20061125015223.GA51565@cdnetworks.co.kr> <f027bef40611251420s6e898e4iba9cf5928266fb5@mail.gmail.com> <200611260331.28847.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 26 Nov 2006, Max Laier wrote:
> On Saturday 25 November 2006 23:20, Nicolae Namolovan wrote:
>> But I need to use it on a production server and the CURRENT one is too
>> unstable, without too much thinking I just run ping -f 127.0.0.1 and
>> after some minutes I got kernel panic, heh.
>
> could you please be more specific about this? My rather recent current
> box is running for over 45min doing "ping -f 127.0.0.1" with no panic or
> other ill behavior so far. After about 10min I disabled the icmp
> limiting which obviously didn't trigger it either. Could you provide a
> back trace or at least a panic message? Thanks.
I haven't seen any problems with ping, but ttcp -u causes the panic in
sbdrop_internal() about half the time when the client ttcp is killed
by ^C. There is apparently a race in close when packets are arriving.
The stack trace on the panicing CPU is (always?):
... sigexit exit1 ... closef ... soclose ...
sbflush_internal sbdrop_internal panic
and on the other CPU, with net.isr.direct=1 it was:
bge_rxeof ... netisr_dispatch ip_input ...
sbappendaddr_locked mb_ctor_mbuf --- trap (NMI IPI for cpustop).
and with net.isr.direct=0, the other CPU was just running "idle: cpuN"
and the bge thread was in ithread_loop.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061126165353.Y47830>