Date: Thu, 22 Nov 2012 21:04:02 -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: <1353643442.69940.45.camel@revolution.hippie.lan> In-Reply-To: <50A150C7.2080805@jetcafe.org> References: <50A150C7.2080805@jetcafe.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-U+0tiqhzPM3RGEvKkQUg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 --=-U+0tiqhzPM3RGEvKkQUg Content-Disposition: inline; filename="arm_cache_writethrough.diff" Content-Type: text/x-patch; name="arm_cache_writethrough.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit diff -r df572d6d53cd sys/arm/arm/pmap.c --- sys/arm/arm/pmap.c Thu Nov 22 16:46:06 2012 -0700 +++ sys/arm/arm/pmap.c Thu Nov 22 20:54:49 2012 -0700 @@ -481,6 +481,16 @@ pmap_pte_init_generic(void) pte_l2_s_cache_mode_pt = L2_C; } +#if 1 // Change data cache from writeback to writethrough + pte_l1_s_cache_mode = L1_S_C; + pte_l2_l_cache_mode = L2_C; + pte_l2_s_cache_mode = L2_C; + + pte_l1_s_cache_mode_pt = L1_S_C; + pte_l2_l_cache_mode_pt = L2_C; + pte_l2_s_cache_mode_pt = L2_C; +#endif + pte_l2_s_prot_u = L2_S_PROT_U_generic; pte_l2_s_prot_w = L2_S_PROT_W_generic; pte_l2_s_prot_mask = L2_S_PROT_MASK_generic; --=-U+0tiqhzPM3RGEvKkQUg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1353643442.69940.45.camel>