arm/173617

[Ian Lepore]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dp_cache_wralloc.diff
Type: text/x-patch
Size: 989 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20130304/200cc90a/attachment.bin>