From owner-freebsd-current@FreeBSD.ORG Tue Jan 27 12:46:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E814210656BF for ; Tue, 27 Jan 2009 12:46:06 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 76EDC8FC24 for ; Tue, 27 Jan 2009 12:46:06 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n0RCjw1h039748 ; Tue, 27 Jan 2009 13:45:59 +0100 (CET) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n0RCjvvj024581; Tue, 27 Jan 2009 13:45:57 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n0RCjuP0024578; Tue, 27 Jan 2009 13:45:56 +0100 (CET) (envelope-from arno) To: Dmitry Marakasov From: "Arno J. Klaassen" References: <20090123221826.GB30982@deprived.panopticon> <20090126144044.GB6054@hades.panopticon> Date: Tue, 27 Jan 2009 13:45:56 +0100 In-Reply-To: <20090126144044.GB6054@hades.panopticon> (Dmitry Marakasov's message of "Mon\, 26 Jan 2009 14\:40\:44 +0000") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.jussieu.fr [134.157.0.168]); Tue, 27 Jan 2009 13:45:59 +0100 (CET) X-Virus-Scanned: ClamAV 0.94.2/8908/Tue Jan 27 09:23:41 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 497F0206.00C by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 497F0206.00C/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 497F0206.00C on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.011 -> S=0.011 X-j-chkmail-Status: Ham Cc: current@freebsd.org Subject: Re: Data corruption with checksum offloading enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2009 12:46:07 -0000 Hello, Dmitry Marakasov writes: > For now I have two cases of corruption - in both cases it is single > difference of one 128 byte block with file offsets 0x65F872 and > 0x61A072. I had a similar problem last April on a 7-stable box reported in a 'nfs-server silent data corruption' thread. I found : - in all failing cases just *one* byte is currupted, 4 or all 8 bits set to zero *and* the original value is one out of the limited subset {1, 8, 9} .... here is the output of `cmp -x $i/BIG $i/BIG2` for some failing cases I saved : 03869a48 09 00 05209d88 09 00 01777148 09 00 00f10f88 09 00 01f4c4c8 11 00 06c3d6c8 11 00 0725ca48 18 00 01608008 09 00 00f3b888 18 00 07aa45c8 29 20 Does your corruption fulfill these characterisations as well? > I was suggested by Andrzej Tobola to try disabling txcsum on a > network interface. I've disabled both rxcsum and txcsum, and that > solved a problem. > > Judging from that this helped Andrzej with sk(4) and me with ale(4) > driver, that's not a single driver problem. Does his mean that we > have global problems with checksum offloading? I could reproduce it with nfe(4) and re(4) ... interestingly enough, I could *not* reproduce it when disabling cpu frequency control ... for what it's worth Best, Arno