Date: Mon, 26 Nov 2012 14:52:40 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: Dreamplug and eSATA problems Message-ID: <1353966760.69940.119.camel@revolution.hippie.lan> In-Reply-To: <CAJ-VmomwQ77b2LDPktw37TAyXYHWvnRBD11a==%2BcPtZ0jW1LhA@mail.gmail.com> References: <50A150C7.2080805@jetcafe.org> <1353643442.69940.45.camel@revolution.hippie.lan> <50B33C7F.2040303@jetcafe.org> <CAJ-VmomwQ77b2LDPktw37TAyXYHWvnRBD11a==%2BcPtZ0jW1LhA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2012-11-26 at 12:57 -0800, Adrian Chadd wrote: > .. hm, is this WT/WB cache handling a general problem with ARM? > > I've had some people comment about the stability of userland on older > ARM platforms (specifically ixp425 based systems) where it worked fine > for kernel-specific things (routing, bridging) but userland was > unstable. > > So I wonder whether there's a more general ARM problem here. > > I'll have an ixp425 setup working soon (the gateworks cambria/avila > boards) as well as the R-Pi and Pandaboard; so I'll be able to do some > userland testing and provide feedback. The only systemic arm cache problem I know of is the partial cacheline flush problem that we haven't even begun to actually fix yet -- it needs some support in the busdma_machdep routines, which I posted a patchset for, and then it needs misbehaving drivers to be tweaked to behave correctly in terms of allocating dma buffers; arm and mips and any other VIVT architectures need this same treatment. But I've fought the various cache flush problems so much in armland that toggling between WB/WT and seeing if the problem follows writeback is pretty much step #2 (step 1 being "recreate the problem"). Usually if the problem follows the writeback, you've got a partial cacheline flush problem. In this case, I instrumented the busdma sync code, and partial flushes are never happening. There could be subtle trouble down in the low-level asm cache flush code for sheeva chips. Unfortunately, the docs for the sheeva mmu are proprietary, so it's hard to evaluate whether that code is doing anything wrong. The most interesting datapoint right now is that the problem happens on 9.1 but not -current. I'm afraid that could be an accident, like maybe it wasn't fixed, just made very unlikely by timing differences. I hope to start investigating that in a few days, but that's a difficult path because a big non-trivial set of patches have to be applied to each checkout just to get a dreamplug to boot. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1353966760.69940.119.camel>