From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 01:19:14 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4DB63723; Tue, 5 Mar 2013 01:19:14 +0000 (UTC) (envelope-from mcgovern@beta.com) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) by mx1.freebsd.org (Postfix) with ESMTP id D3E0A742; Tue, 5 Mar 2013 01:19:13 +0000 (UTC) Received: from [199.165.180.44] ([199.165.180.44]) by spoon.beta.com (8.14.5/8.14.5) with ESMTP id r251J74w017956; Mon, 4 Mar 2013 20:19:08 -0500 (EST) (envelope-from mcgovern@beta.com) Subject: Re: arm/173617 From: "Brian J. McGovern" To: Ian Lepore In-Reply-To: <1362437526.1195.293.camel@revolution.hippie.lan> References: <201303042155.r24LtN7a016998@spoon.beta.com> <1362437526.1195.293.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Organization: B.E.T.A. Date: Tue, 05 Mar 2013 01:19:07 +0000 Message-ID: <1362446347.1382.4.camel@fbsd-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.5 required=5.0 tests=HELO_MISC_IP,RDNS_NONE autolearn=no version=3.3.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on spoon.beta.com Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mcgovern@beta.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 01:19:14 -0000 On Mon, 2013-03-04 at 15:52 -0700, Ian Lepore wrote: > On Mon, 2013-03-04 at 16:55 -0500, Brian J. McGovern wrote: > > I have been chasing down a disk write problem my OpenRD. In my research, I > > ran across arm/173617, which discusses file corruption while downloading ports > > via fetch, which is how I first noticed the issue. However, contrary to the PR, > > the issues does not appear to be in the network interface, but rather on the > > writing of the file to disk. The problem appears global - I've tested SATA, > > USB (umass), and SD/MMC interfaces. I've also had problems with NFS mounts in > > the past, but have not verified that the issues are the same. > > > > I have not chased down a particular size, but "small" writes (e.g. a config > > file, .c file, etc.) appear to work correctly at all times. "Large" writes > > (I usually see it on files a MB or larger, but this may be a function of > > opportunity) will typically see some number of bytes set to zero. To reproduce > > the problem, I wrote a short application that writes sequentially incrementing > > 64-bit integers out to disk. (e.g. 0, 1, 2, 3...), and one that reads them > > back. > > > > The result matrix clearly showed the problem is on the write side - writing > > files on other systems and reading them back on the OpenRD works fine. Writing > > them on the OpenRD causes read back failures, both on the OpenRD _and_ other > > hosts. I have also found that setting the file handle O_SYNC (or mounting > > the filesystem in sync mode) eliminates the problem. > > > > Has anyone seen/fixed this problem? I'd hate to waste much more time with it > > if its a known problem, or there is a closed PR I haven't found yet. > > > > You didn't say what version of freebsd you're working with. I saw a > problem like that a while back on my similar DreamPlug; the symptom was > random chunks of corruption that were always 32 bytes of wrong data > each. I think the fix for that was to disable cache write-allocate on > sheeva chipsets; that fix came into -current along with all the armv6 > changes, but I have it as a separate patch too. > > -- Ian > > > Sorry. The tests were specifically with 9.1-RELEASE. Most of the time, I've seen 64 bits of corruption, and all zeros, rather than "wrong data", although early on I did see some other values occur, although I thought it may have been a 32 vs. 64 bit issues with ints until I went to uint64_t. Is -current working well enough to build a stable platform? Can you email me the patch privately, and I'll see if I can get it working on 9? -Brian