From owner-freebsd-arm@FreeBSD.ORG Wed Dec 16 19:44:00 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FC09106566B for ; Wed, 16 Dec 2009 19:44:00 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id A94F28FC15 for ; Wed, 16 Dec 2009 19:43:59 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 671E8C427A; Wed, 16 Dec 2009 20:44:00 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id Z-dL9HbejmK3; Wed, 16 Dec 2009 20:43:59 +0100 (CET) Received: from [192.168.133.14] (nat2-102.ghnet.pl [91.150.223.102]) by smtp.semihalf.com (Postfix) with ESMTPSA id 62F19C41E7; Wed, 16 Dec 2009 20:43:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <26813898.post@talk.nabble.com> Date: Wed, 16 Dec 2009 20:43:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1284BB72-0FAC-49E4-86FB-D44D9FD630B0@semihalf.com> References: <26803523.post@talk.nabble.com> <4B28C608.1070802@gmail.com> <4B28CFCD.3000401@semihalf.com> <26811801.post@talk.nabble.com> <4B28FF6F.4090601@semihalf.com> <26813898.post@talk.nabble.com> To: RuiDC X-Mailer: Apple Mail (2.1077) Cc: freebsd-arm@freebsd.org Subject: Re: fetch data corruption on local fs X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 19:44:00 -0000 On 2009-12-16, at 17:26, RuiDC wrote: > Grzegorz Bernacki wrote: >>=20 >> As I understand setting just "-o noclusterr -o noclusterw" didn't = help=20 >> you, right? If so use just "-o sync". >>=20 >=20 > I tried with three configurations: > 1. just -o sync > 2. just noclustered read/writes > 3. both sync and noclustered > All three worked, but am I correct in thinking that configuration 3 is = the > most conservative? =46rom our investigations back then disabling clustering should suffice, = forcing sync operation is a bigger hammer (against performance). > The sheevaplug build doesn't produce loader.conf or loader.4th, an ls = of my > /boot directory is below, although according to man pages for = loader.conf: > If no /boot/loader.rc exists at installworld time, one with the above = lines > will be installed.=20 >=20 > So I do not know if this is normal for a Sheevaplug build. Can anyone > confirm? > Is it OK to copy these over from an i386 machine??? > > splug# ls -l /boot > total 352 > drwxr-xr-x 2 root wheel 512 Dec 15 17:04 defaults > drwxr-xr-x 2 root wheel 512 Dec 15 17:04 firmware > drwxr-xr-x 2 root wheel 512 Dec 16 13:53 kernel > -r--r--r-- 1 root wheel 13320 Dec 16 13:52 loader.help > drwxr-xr-x 2 root wheel 512 Dec 15 17:04 modules > -r-xr-xr-x 1 root wheel 166236 Dec 16 13:52 ubldr > -r-xr-xr-x 1 root wheel 166236 Dec 16 11:52 ubldr.old > drwxr-xr-x 2 root wheel 512 Dec 15 17:04 zfs > It seems loader.conf and .4th are not hooked up to the ARM install = scripting/makefile; they are not required to get the loader initially = working, but you can copy them from i386 world if needed. Note that running ubldr on ARM requires the underlying U-Boot to be = compiled with CONFIG_API option enabled, which is only available in main = line U-Boot since ver. 1.3.2; what is your version? Rafal