From owner-freebsd-net@FreeBSD.ORG Thu Feb 15 22:40:41 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82A2B16A401 for ; Thu, 15 Feb 2007 22:40:41 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from rock.polstra.com (rock.polstra.com [64.119.0.113]) by mx1.freebsd.org (Postfix) with ESMTP id 647A713C441 for ; Thu, 15 Feb 2007 22:40:41 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) (authenticated bits=0) by rock.polstra.com (8.13.8/8.13.8) with ESMTP id l1FMee8k004405; Thu, 15 Feb 2007 14:40:40 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 15 Feb 2007 14:40:40 -0800 (PST) From: John Polstra To: Kip Macy X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (rock.polstra.com [64.119.0.113]); Thu, 15 Feb 2007 14:40:41 -0800 (PST) Cc: freebsd-net@freebsd.org Subject: Re: bge0: discard frame w/o packet header 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: Thu, 15 Feb 2007 22:40:41 -0000 On 15-Feb-2007 Kip Macy wrote: > I mean a bug in if_bge.c - there are a lot of ways that this could > happen - not calling M_GETHDR, mis-calling m_pullup etc. There's no obvious bug in that part of the driver, but I'm going to instrument it on the offending system to try to find out just what's going on. When a packet is received, the driver allocates an mbuf to replace the one that the received packet occupied. It does that in one of two ways. The normal case is to call m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR). For that to return an mbuf without M_PKTHDR set would require a pretty serious bug in the mbuf or UMA code. The less common case is that the driver discards the just-received packet and reuses the mbuf it occupied. It does that if the m_getcl call failed (i.e., we are out of mbufs) or if the flags in the descriptor show that the just-received packet had errors. If there's a driver bug it's probably in this code path, but I don't see it yet. Hopefully, the diagnostics I've added will point to the problem. John