Date: Mon, 04 Mar 2013 18:47:33 -0700 From: Ian Lepore <ian@FreeBSD.org> To: mcgovern@beta.com Cc: freebsd-arm@FreeBSD.org Subject: Re: arm/173617 Message-ID: <1362448053.1195.304.camel@revolution.hippie.lan> In-Reply-To: <1362446347.1382.4.camel@fbsd-laptop> References: <201303042155.r24LtN7a016998@spoon.beta.com> <1362437526.1195.293.camel@revolution.hippie.lan> <1362446347.1382.4.camel@fbsd-laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-2B+lSvL55LM46qugFifW
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
On Tue, 2013-03-05 at 01:19 +0000, Brian J. McGovern wrote:
> 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
Here's the patch I prepared for 8.2 at work, it applies cleanly to
9-stable (it's even simpler than I remembered).
The state of -current is good for DreamPlug. I'd actually appreciate
folks testing other sheeva-based platforms and let me know about any
kernel config or dts file changes you need to do. I'd like to get
support for all the GlobalScale computers solidified in 9-stable
sometime soon.
-- Ian
--=-2B+lSvL55LM46qugFifW
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.
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);
}
--=-2B+lSvL55LM46qugFifW--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1362448053.1195.304.camel>