From owner-freebsd-arm@FreeBSD.ORG Sat Dec 1 22:58:46 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68296C87 for ; Sat, 1 Dec 2012 22:58:46 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 536608FC08 for ; Sat, 1 Dec 2012 22:58:42 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qB1MwSuX099417 for ; Sat, 1 Dec 2012 15:58:35 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qB1Mw5gI043997; Sat, 1 Dec 2012 15:58:05 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Dreamplug and eSATA problems From: Ian Lepore To: Dave Hayes In-Reply-To: <50B33C7F.2040303@jetcafe.org> References: <50A150C7.2080805@jetcafe.org> <1353643442.69940.45.camel@revolution.hippie.lan> <50B33C7F.2040303@jetcafe.org> Content-Type: multipart/mixed; boundary="=-4BjipPIgMEV4ubsnYhPl" Date: Sat, 01 Dec 2012 15:58:05 -0700 Message-ID: <1354402685.69940.571.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 22:58:46 -0000 --=-4BjipPIgMEV4ubsnYhPl Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, 2012-11-26 at 01:55 -0800, Dave Hayes wrote: > On 11/22/12 20:04, Ian Lepore wrote: > > It'll be a while before I can get back to this and start tracking down > > the point at which the problem went away in -current. If you want a > > quick workaround for now, the attached patch will set the data cache to > > writethrough (the performance hit isn't as bad as you'd think). > > Thank you! This appears to work fine; I've built several ports including > Perl, and they appear to work. Usually if a machine can build ports, > it's got fairly solid hardware. > > As to a performance hit, I'm not really informed enough about the arm > architecture to notice. This is the first I've been able to really use > this box, so I'm considering that enough for now. > Alright, I tracked down the problem today; patch is attached. Undo that prior patch that disabled writeback and try this instead. Prior to the import of the armv6 support, the code unconditionally enabled the "allocate on write miss" MMU feature. One of the things that came with the armv6 import was new logic to leave that bit alone when setting up the cache stuff, similar to the attached patch (but names of things changed too, so a direct MFC isn't possible). I guess the idea is to leave that feature in whatever state the bootloader set it to; maybe the feature works on some SoCs and not others. If the armv6 support isn't going to be MFC'd any time soon, it'd be nice if this fix could get commited to 9-stable as an interim fix. -- Ian --=-4BjipPIgMEV4ubsnYhPl Content-Disposition: inline; filename="dp_cache_wralloc.diff" Content-Type: text/x-patch; name="dp_cache_wralloc.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Do not enable allocating a cache line on write access. Instead, leave that feature in whatever state the bootloader set it to, on the theory that the firmware that comes with the unit knows best. This fixes intermittant cache line corruptions during bulk network data flow. diff -r df572d6d53cd -r a142512ee876 sys/arm/arm/cpufunc.c --- sys/arm/arm/cpufunc.c Thu Nov 22 16:46:06 2012 -0700 +++ sys/arm/arm/cpufunc.c Sat Dec 01 15:38:59 2012 -0700 @@ -1067,13 +1067,13 @@ set_cpufuncs() */ if (cputype == CPU_ID_MV88FR571_VD || cputype == CPU_ID_MV88FR571_41) { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN | FC_L2_PREF_DIS); } else { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN); } --=-4BjipPIgMEV4ubsnYhPl--