From owner-freebsd-current@FreeBSD.ORG Tue Jan 27 13:45:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71D93106566C for ; Tue, 27 Jan 2009 13:45:21 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2A83A8FC21 for ; Tue, 27 Jan 2009 13:45:21 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LRoFl-0008EO-VB; Tue, 27 Jan 2009 16:45:22 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 0FF24A78F; Tue, 27 Jan 2009 16:45:36 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 511FD108838; Tue, 27 Jan 2009 16:46:17 +0000 (UTC) Date: Tue, 27 Jan 2009 16:46:17 +0000 From: Dmitry Marakasov To: "Arno J. Klaassen" Message-ID: <20090127164617.GA93440@hades.panopticon> References: <20090123221826.GB30982@deprived.panopticon> <20090126144044.GB6054@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-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 13:45:21 -0000 * Arno J. Klaassen (arno@heho.snv.jussieu.fr) wrote: > > 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? Nope, as I've written before, it's corruption of single 128 byte block. I've deleted samples during the upgrade process, but I think I'll turn *xcsum back on and do some more tests with NFS, and netcat transfers. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru