From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 12:56:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1719D106564A for ; Sun, 8 Feb 2009 12:56:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E58688FC16 for ; Sun, 8 Feb 2009 12:56:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 83A4A46B09; Sun, 8 Feb 2009 07:56:21 -0500 (EST) Date: Sun, 8 Feb 2009 12:56:21 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Jeremy In-Reply-To: <20090208104253.GB31876@test71.vk2pj.dyndns.org> Message-ID: References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> <20090208104253.GB31876@test71.vk2pj.dyndns.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 12:56:22 -0000 On Sun, 8 Feb 2009, Peter Jeremy wrote: > On 2009-Feb-08 11:31:45 +0200, Danny Braniss wrote: >> Q: with rxcsum on, and a bad checksum packet is received, is it >> dropped by the NIC? if not, then it somewhat explains the behaviour > > If checksum offloading is working correctly then a bad packet should be > dropped by the NIC. If checksum offloading isn't working correctly then you > can wind up in the situation where both the NIC and the driver think the > other party has verified the checksum. It's also possible that you may be > running into corruption during DMA transfer from the NIC to RAM. ISTR there > have been some issues reported recently with checksum offloading on some > NICs - though I don't have details to hand - you might like to search the > lists. > >> changing the nic is tough, but if needed will be done. > > If disabling checksum offloading fixes the problem and the additional CPU > load is acceptable (at least until you find a real fix) then there's no need > to change NICs. Actually, my understanding was that packets with bad checksums are delivered to software, and flag the descriptor ring header for each packet tells us whether the checksum was (a) checked and (b) validated by the hardware. We then propagate these to mbuf flags so that higher stack layers know whether or not to calculate the checksum themselves. Regardless of the specifics, though, packets with checked but bad checksums shouldn't make it to the socket layer where they would be visible to NFS. If the NIC is marking apparently bad packets as good, there are a number of possible sources -- be it bad checksum handling in the card, corruption between the card and higher levels of the stack (a DMA problem, as you point out, would have this symptom). Robert N M Watson Computer Laboratory University of Cambridge