From owner-freebsd-stable@FreeBSD.ORG Fri Mar 5 03:55:06 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C610616A4CE for ; Fri, 5 Mar 2004 03:55:06 -0800 (PST) Received: from ngfl.dialnet.com (ngmail.ngfl.dialnet.com [212.44.44.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD7EC43D31 for ; Fri, 5 Mar 2004 03:55:05 -0800 (PST) (envelope-from ict@cardinalnewman.coventry.sch.uk) Received: from ngmfilt.ngfl.dialnet.com [212.44.44.121] by ngfl.dialnet.com with ESMTP (SMTPD32-6.06) id A976A6EA0134; Fri, 05 Mar 2004 11:50:14 +0000 Received: from relay.ngfl.dialnet.com (unverified) by ngmfilt.ngfl.dialnet.com for ; Fri, 5 Mar 2004 11:49:12 +0000 Received: from firewall.cardinalnewman.lan ( [172.30.0.70]) by relay.ngfl.dialnet.com with SMTP (MailShield v2.04 - WIN32 Jul 17 2001 17:12:42); Fri, 05 Mar 2004 11:52:17 -0000 Received: from mail.cardinalnewman.lan (mail.cardinalnewman.lan [192.168.0.3]) i25Bs16s005793 for ; Fri, 5 Mar 2004 11:54:01 GMT (envelope-from ict@cardinalnewman.coventry.sch.uk) Received: from dumpster.cardinalnewman.lan (dumpster.cardinalnewman.lan [192.168.0.9])i25Bs0io035307 for ; Fri, 5 Mar 2004 11:54:00 GMT (envelope-from ict@cardinalnewman.coventry.sch.uk) From: ict technician Organization: Cardinal Newman School To: freebsd-stable@freebsd.org Date: Fri, 5 Mar 2004 11:54:00 +0000 User-Agent: KMail/1.5.4 References: <200403021228.17716.ict@cardinalnewman.coventry.sch.uk> <200403021434.27420.ict@cardinalnewman.coventry.sch.uk> <200403041208.46884.ict@cardinalnewman.coventry.sch.uk> In-Reply-To: <200403041208.46884.ict@cardinalnewman.coventry.sch.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403051154.00447.ict@cardinalnewman.coventry.sch.uk> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-32.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Filter-Version: 1.11a (mail.cardinalnewman.lan) X-SMTP-HELO: firewall.cardinalnewman.lan X-SMTP-MAIL-FROM: ict@cardinalnewman.coventry.sch.uk X-SMTP-RCPT-TO: freebsd-stable@freebsd.org X-SMTP-PEER-INFO: [172.30.0.70] Subject: Re: em0 checksum errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2004 11:55:06 -0000 On Thursday 04 March 2004 12:08 pm, ict technician wrote: > On Tuesday 02 March 2004 2:34 pm, ict technician wrote: > > On Tuesday 02 March 2004 12:28 pm, ict technician wrote: > > > I've been testing an application which uses UDP. I was having > > > difficulties so I started taking packet dumps. I noticed that many > > > packets have bad checksums. The errors are mostly on UDP packets but I > > > do see some TCP packets with errors also. This occurs on system > > > applications without the new app. running, e.g. dns/ssh > > > > > > This is reproducable on more than one system, although the NICs are > > > probably from the same batch, as I bought a box of 5 out of 7 in use. > > > Systems are 4.9-RELEASEp1/p2. > > > > > > The cards are Intel PRO/1000 MT Server. I'll get the numbers off the > > > card shortly. > > > > > > One box on stable (18th Feb) seems okay so I'm going to try stable on > > > my test box and see if that cures it. > > > > > > I won't spam the list with the dump. > > > > replies to self - how uncouth. > > > > While it's building I decide to re-read the recent thread > > http://docs.freebsd.org/cgi/mid.cgi?6.0.3.0.0.20040226131930.10513908 > > > > I'd discounted this as I wasn't seeing the EEPROM message. > > > > Sure enough, moving the em0 card seems to fix the problem. > > > > I'll reply to self again once I confirm the conflicting item ;) > > Aaarrrgghhh, evil PC hardware. > > Once I'd moved the NIC it decided to work. However, I moved the card back > to it's original slot and could no longer reproduce the fault. > > All the other boxes with these cards are production but I can play with the > "backup server" which only need to run at night. > > Tried a cold boot. No joy. > Then I swapped the NIC. No joy. Noted that it's different C31527-002 vs > A92165-004. Not listed as supported but according to Intel it's the same > part. > > Much swapping of cards to no avail. Trying more stuff :(( Drat and double drat! It appears to be "a feature". The "broken" packets appear to deliver okay. Now if I understand things correctly these cards can do checksum offloading. I'm guessing that the packets are snarfed before the card can fix-up the checksum. Can A N Expert confirm my conjecture? In any case can anyone confirm the result? I'm doing #tcpdump -lv -s1500 | grep bad Wierd thing is one box (only) works. Naturally this is the box I tested on. For the record it's a GA-7VAXP-A Ultra. I'm willing to take a look at this, but I'm no kernel hacker. Is it in em/bpf/tcpdump/network stack? It's probably not the recent PAE related changes since I tried 4.7, 4.8, 4.9, and 5.2.1RC. Also tried latest driver from Intel site. I still need to track down the network problems with the new app, and having a broken tcpdump is cramping my style. Cheers -- i j hart ICT Technician Cardinal Newman Catholic School & Community College