Date: Sat, 01 Dec 2012 15:58:05 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Dave Hayes <dave@jetcafe.org> Cc: freebsd-arm@freebsd.org Subject: Re: Dreamplug and eSATA problems Message-ID: <1354402685.69940.571.camel@revolution.hippie.lan> In-Reply-To: <50B33C7F.2040303@jetcafe.org> References: <50A150C7.2080805@jetcafe.org> <1353643442.69940.45.camel@revolution.hippie.lan> <50B33C7F.2040303@jetcafe.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1354402685.69940.571.camel>