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]
[EMAIL PROTECTED]: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]
[EMAIL PROTECTED]: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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
