Re: ping -f panic [Re: Marvell Yukon 88E8056 FreeBsd Drivers]


On Sun, 26 Nov 2006, Bruce Evans wrote:

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.

Historically, sbflush panics have been a sign of a driver<->stack race, in which the driver touches the mbuf [chain] after injecting it into the stack, corrupting the socket buffer state. For example, freeing it, appending another mbuf, changing the length, etc. It often triggers in sbflush because we notice the inconsistency when we close the socket and flush the buffer later. I wouldn't preclude a network stack bug, but I would definitely take a look at the driver in detail first, making sure all error cases are handled properly, etc.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • [PATCH x86 for review II] [14/39] x86_64: cleanup Doc/x86_64/ files
    ... Linux/x86-64 supports CPU hotplug now. ... Interrupt stack. ... This feature is called the Interrupt Stack Table ... Used for interrupt 12 - Stack Fault Exception. ...
    (Linux-Kernel)
  • Re: [git pull] core fixes
    ... > Suresh and I looked at the oops and looks like the root cause is in ... > - CPU B gets the call function interrupt and starts going through the ... > CPU A's stack, as that element is still in call_function_queue ... > - CPU B sees the wait flag and just clears the flag ...
    (Linux-Kernel)
  • RE: tcp/ip hardware offload
    ... This isn't just TCP/IP stack specific. ... I know for CPU thermal testing Intel ... > announced gigabit network adapters with full protocol offload. ...
    (Vuln-Dev)
  • Re: [PATCH] no need to check for NULL before calling kfree()-fs/ext2/
    ... >> that the return address be written to memory (the stack), ... > 1) On a modern cpu, a miss of the branch predictor is quite expensive. ... It can't be on machines that have a "call" instruction. ... That's what the advertising hype is all about. ...
    (Linux-Kernel)
  • Re: [Fastboot] [PATCH 1/3] stack overflow safe kdump (2.6.18-rc1-i386) - safe_smp_proces
    ... thread_info which resides at the bottom of the stack. ... cpu in the first place. ... The implementation of send_IPI_allbutself in the different architectures ... cpu_clear, mask) ...
    (Linux-Kernel)