panic ixgbevf / SMP under high network load

[Rémi Pauchet]

Hi

I have the same crash with FreeBSD 10-current

FreeBSD freebsd10 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r241761: Sat Oct 20 07:40:33 UTC 2012     root at kaos.glenbarber.us:/usr/obj/usr/src/sys/GENERIC  amd64

Sorry for the screenshots: panic doesn't dump the memory to the swap, I can't figure out why

I use udp frames (size 700) so this load is not supposed to produce ip fragmentation.

And again, the panic happens with 4 vcpus, no issue with 1 vcpu.

Regards,
Rémi






Le 25 oct. 2012 à 18:40, Gleb Smirnoff a écrit :

> On Thu, Oct 25, 2012 at 10:06:40AM +0200, R?mi Pauchet wrote:
> R> I'm testing network performance of FreeBSD using vmware esxi 5.1 with SR-IOV
> R> 
> R> I'm using  FreeBSD 8.3 kernel GENERIC, 4 cpus, ixgbevf driver with an Intel 82599EB dual 10 Gbps network interface
> R> 
> R> After a few seconds of udp ipv4 load (5Gbps x2, frame size 700), I have the following panic :
> R> 
> R> (kgdb) bt
> R> #0  doadump () at pcpu.h:224
> R> #1  0xffffffff8060ab90 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:441
> R> #2  0xffffffff8060b031 in panic (fmt=Variable "fmt" is not available.
> R> ) at /usr/src/sys/kern/kern_shutdown.c:614
> R> #3  0xffffffff80900b80 in trap_fatal (frame=0xc, eva=Variable "eva" is not available.
> R> ) at /usr/src/sys/amd64/amd64/trap.c:825
> R> #4  0xffffffff80900ed1 in trap_pfault (frame=0xffffff800016a620, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741
> R> #5  0xffffffff8090138f in trap (frame=0xffffff800016a620) at /usr/src/sys/amd64/amd64/trap.c:478
> R> #6  0xffffffff808e88e4 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228
> R> #7  0xffffffff80667ef7 in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:542
> R> #8  0xffffffff8071c8c2 in ip_fragment (ip=0xffffff0001a3700e, m_frag=0xffffff800016a838, mtu=Variable "mtu" is not available.
> R> ) at /usr/src/sys/netinet/ip_output.c:819
> R> #9  0xffffffff8071d93a in ip_output (m=0xffffff00019fd900, opt=Variable "opt" is not available.
> R> ) at /usr/src/sys/netinet/ip_output.c:650
> R> #10 0xffffffff8071a13a in ip_forward (m=0xffffff00019fd900, srcrt=Variable "srcrt" is not available.
> R> ) at /usr/src/sys/netinet/ip_input.c:1521
> R> #11 0xffffffff8071b77c in ip_input (m=0xffffff00019fd900) at /usr/src/sys/netinet/ip_input.c:729
> R> #12 0xffffffff806c652e in netisr_dispatch_src (proto=1, source=Variable "source" is not available.
> R> ) at /usr/src/sys/net/netisr.c:859
> R> #13 0xffffffff806bc5cd in ether_demux (ifp=0xffffff000168e800, m=0xffffff00019fd900) at /usr/src/sys/net/if_ethersubr.c:896
> R> #14 0xffffffff806bc9d7 in ether_input (ifp=0xffffff000168e800, m=0xffffff00019fd900) at /usr/src/sys/net/if_ethersubr.c:755
> R> #15 0xffffffff803ee03e in ixv_rxeof (que=0xffffff0001643880, count=117) at /usr/src/sys/dev/ixgbe/ixv.c:3256
> R> #16 0xffffffff803ef50b in ixv_handle_que (context=Variable "context" is not available.
> 
> I have looked at several panics like this, and it appears that ip_fragment()
> is entered with incorrect byte order here. I failed to understand how this happens,
> and eventually had made the network stack in head to run consistently in network
> byte order, never modifying a forwarded packet.
> 
> If you can run recent 10-CURRENT under same tests, I'd like to know the results.
> 
> -- 
> Totus tuus, Glebius.