From owner-freebsd-net@FreeBSD.ORG Fri Oct 12 18:25:15 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2589316A469 for ; Fri, 12 Oct 2007 18:25:15 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 00AA613C442; Fri, 12 Oct 2007 18:25:12 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <470FBC05.6010601@FreeBSD.org> Date: Fri, 12 Oct 2007 20:25:09 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jack Vogel , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: em driver sending bad packet lengths X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2007 18:25:15 -0000 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: 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: 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