From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 04:09:32 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D54861065674; Mon, 9 Feb 2009 04:09:32 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 484C98FC19; Mon, 9 Feb 2009 04:09:32 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.0.7.197] (r74-193-77-79.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.77.79]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id n193ImYQ045191; Sun, 8 Feb 2009 21:18:49 -0600 (CST) (envelope-from anderson@freebsd.org) Message-Id: <205598DD-B746-4236-9140-855811BAE21C@freebsd.org> From: Eric Anderson To: Danny Braniss In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Feb 2009 21:47:01 -0600 References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94.1/8966/Sun Feb 8 17:43:40 2009 on ns.trinitel.com X-Virus-Status: Clean X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ns.trinitel.com Cc: Ross Dickey , Peter Jeremy , hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 04:09:34 -0000 On Feb 8, 2009, at 3:31 AM, Danny Braniss wrote: >> >> --jI8keyz6grp/JLjh >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> On 2009-Feb-08 10:45:13 +0200, Danny Braniss >> wrote: >>> Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard >>> frame w/o=20 >>> leading ethernet header (len 0 pkt len 0) >> =2E.. >>> Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ >>> sequence in=20 >>> "rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM- >>> ^KoM- a= >> base" >>> Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet >>> length= >> =20 >>> (2068989523) from nfs server sunfire:/dist >>> >>> which seems to point fingers at bce... >> >> It does rather suggest that bce is not behaving. What happens if you >> turn off checksum off-loading? This should make the kernel drop the >> corrupt packets instead of trying to process them. If practical, you >> could also try (temporarily) plugging in a different NIC. >> > I have, and now it's a matter of waiting... > 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 > > changing the nic is tough, but if needed will be done. > danny > >> Peter Jeremy We were hitting this quite a bit (also bce), and updated to a recent 7- branch and it seems to be behaving better for now. Running 12 days so far (which is better than what we had been seeing). Eric