From owner-freebsd-stable@FreeBSD.ORG Tue Mar 9 04:51:48 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 AAB2016A4CE for ; Tue, 9 Mar 2004 04:51:48 -0800 (PST) Received: from ngfl.dialnet.com (ngmail.ngfl.dialnet.com [212.44.44.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 711E243D60 for ; Tue, 9 Mar 2004 04:51:47 -0800 (PST) (envelope-from ict@cardinalnewman.coventry.sch.uk) Received: from ngmfilt2.ngfl.dialnet.com [212.44.44.78] by ngfl.dialnet.com with ESMTP (SMTPD32-6.06) id ACBB2BB30108; Tue, 09 Mar 2004 12:46:51 +0000 Received: from relay.ngfl.dialnet.com (unverified) by ngmfilt2.ngfl.dialnet.com for ; Tue, 9 Mar 2004 12:52:00 +0000 Received: from firewall.cardinalnewman.lan ( [172.30.0.70]) by mail.withinfields.calderdale.sch.uk with SMTP (MailShield v2.04 - WIN32 Jul 17 2001 17:12:42); Tue, 09 Mar 2004 12:49:54 -0000 Received: from mail.cardinalnewman.lan (mail.cardinalnewman.lan [192.168.0.3]) i29Cpc6s016050 for ; Tue, 9 Mar 2004 12:51:38 GMT (envelope-from ict@cardinalnewman.coventry.sch.uk) Received: from dumpster.cardinalnewman.lan (dumpster.cardinalnewman.lan [192.168.0.9])i29Cpbio085195 for ; Tue, 9 Mar 2004 12:51:37 GMT (envelope-from ict@cardinalnewman.coventry.sch.uk) From: ict technician Organization: Cardinal Newman School To: freebsd-stable@freebsd.org Date: Tue, 9 Mar 2004 12:51:37 +0000 User-Agent: KMail/1.5.4 References: <200403021228.17716.ict@cardinalnewman.coventry.sch.uk> <200403041208.46884.ict@cardinalnewman.coventry.sch.uk> <200403051154.00447.ict@cardinalnewman.coventry.sch.uk> In-Reply-To: <200403051154.00447.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: <200403091251.37386.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: Tue, 09 Mar 2004 12:51:48 -0000 On Friday 05 March 2004 11:54 am, ict technician wrote: > 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 Haven't worked out how the driver works yet, but disabling the hardware checksum "fixes" the problem for me. I've filed a pr kern/63982 and I'll copy it to those lovely Intel people. -- i j hart ICT Technician Cardinal Newman Catholic School & Community College