em driver sending bad packet lengths

I am seeing the em driver on 7.0 sending packets with bad UDP (and apparently sometimes IP) packet length fields. This is from UDP NFS traffic (90MB/sec over gige). These packets are dropped on reception by the kernel and counted.

Here is a tcpdump trace showing some bad packets:

17:50:27.912629 IP bad-len 0
17:50:27.912748 IP bad-len 0
17:50:27.912764 IP bad-len 0

I havent yet caught a better tcpdump of the UDP bad packets but they are logged by netstat -s

hydra1# netstat -s -p udp
udp:
120091992 datagrams received
0 with incomplete header
1775 with bad data length field
^^^^
14840 with bad checksum
0 with no checksum
16 dropped due to no socket
258 broadcast/multicast datagrams undelivered
0 dropped due to full socket buffers
0 not for hashed pcb
120075103 delivered
120190737 datagrams output
0 times multicast source filter matched

Disabling txcsum and rxcsum didnt help.

em0: <Intel(R) PRO/1000 Network Connection Version - 6.5.3> port 0x2000-0x201f mem 0xd8a00000-0xd8a1ffff irq 18 at device 0.0 on pci4
em0: Ethernet address: 00:30:48:33:54:ca
em0: [FILTER]

em0@pci4:0:0: class=0x020000 card=0x000015d9 chip=0x10968086 rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'PRO/1000 EB Network Connection'
class = network
subclass = ethernet

em0: <Intel(R) PRO/1000 Network Connection Version - 6.5.3> port 0x4000-0x401f mem 0xe1000000-0xe101ffff irq 16 at device 0.0 on pci18
em0: Ethernet address: 00:30:48:8f:55:48
em0: [FILTER]

em0@pci18:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'PRO/1000 PM'
class = network
subclass = ethernet

The second-order effect from this is that our NFS client currently misbehaves when UDP packets are dropped, and this leads to data corruption.

Kris
_______________________________________________
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

  • Re: Overhead, UDP: Many packets on 1 socket vs. one packet and many ?sockets.
    ... a gigabit LAN network using UDP. ... into "frames" and each device frame is a single UDP packet. ... information in the data packets. ... over each of those sockets. ...
    (comp.unix.programmer)
  • Re: Determining if it is "safe" to send UDP packets
    ... IMHO for "reliable" UDP you need to use some Quality of service ... Maybe your network is QoS enabled and your traffic gets classified as "below ... > the sender's OS that is throwing the UDP packets away. ... > next 100%-x% are not send, they are almost all completely lost. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: em driver sending bad packet lengths
    ... This is from UDP NFS ... Here is a tcpdump trace showing some bad packets: ... 258 broadcast/multicast datagrams undelivered ... device = 'PRO/1000 EB Network Connection' ...
    (freebsd-net)
  • Re: Loosing UDP packets...
    ... The applications I support send lots of UDP via ... Sometimes all the packets hit the wire, ... Perhaps that is only for a non-blocking socket - per my stuff above? ... as I don't send> MTU datagrams. ...
    (comp.os.linux.networking)
  • Overhead, UDP: Many packets on 1 socket vs. one packet and many sockets.
    ... gigabit LAN network using UDP. ... information in the data packets. ... Create a new socket for each of these new pieces of data. ...
    (comp.unix.programmer)