Dreamplug and eSATA problems

[Ian Lepore]

On Mon, 2012-11-12 at 11:40 -0800, Dave Hayes wrote:
> After successfully booting my dreamplug to 9.1-PRERELEASE, I hooked an eSATA drive to my dreamplug. It partitioned and formatted fine (using
> GPT and UFS2). Now when I try to fetch something from the net (using...
> "fetch" ;) ) I get file corruption. An example:
> 
> # fetch http://unbound.net/downloads/unbound-1.4.18.tar.gz
> # sha256 unbound-1.4.18.tar.gz 
> SHA256 (unbound-1.4.18.tar.gz) = 178e065d2e443dc8fa579fa762a755687e9f79ddb93a7afe1c8f80ca38899158
> # fetch http://unbound.net/downloads/unbound-1.4.18.tar.gz
> SHA256 (unbound-1.4.18.tar.gz) = 88a1ae10c6bf6b28f283335ec44a23975ca2d8300d776e01c04db1878a21c615
> 
> This only appears to happen when fetching to the eSATA drive. Fetching to the attached USB stick or the internal SD card does not have this issue. 
> 
> I'm not sure what's going on here, and I'm hoping someone can shed light on this issue so it can be resolved. 
> [dmesg snipped]

I found some time today to get my new DP running.  At first I couldn't
recreate this problem no matter what I tried.  Then I noticed you're
running 9.1-prerelease and I was trying with -current.  I built 9.1-RC3
and sure enough, with that I see the same problem.

It actually appears to have nothing to do with sata, I can get it to
happen on a really minimal system (usb, sata, sound, iic drivers all
disabled).  I boot via tftp, mount root over nfs, and then I can just
cd /tmp (a memory disk) and use tftp to get a 10M file full of zeroes,
and more times than not there are 32-byte chunks of non-zero values in
it.  It seems to require bulk network data to trigger the glitches; I
never have any trouble launching apps or anything that does small
intermittant network stuff, even with root using nfs.

I can turn the problem off by changing the data cache from writeback to
write-through.  So all in all, it looks like a cacheline flush problem,
but it doesn't appear to be the usual partial cacheline flush problems,
because I instrumented the code to check for that, and no partial
flushes are happening during the tftp operations that get corrupted
data.

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).  

-- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: arm_cache_writethrough.diff
Type: text/x-patch
Size: 630 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20121122/dc12d54b/attachment.bin>