From owner-freebsd-arm@FreeBSD.ORG Fri Nov 23 04:04:39 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01D2B676 for ; Fri, 23 Nov 2012 04:04:38 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 76AD18FC08 for ; Fri, 23 Nov 2012 04:04:38 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qAN44Pke046952 for ; Thu, 22 Nov 2012 21:04:32 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qAN442be033469; Thu, 22 Nov 2012 21:04:03 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Dreamplug and eSATA problems From: Ian Lepore To: Dave Hayes In-Reply-To: <50A150C7.2080805@jetcafe.org> References: <50A150C7.2080805@jetcafe.org> Content-Type: multipart/mixed; boundary="=-U+0tiqhzPM3RGEvKkQUg" Date: Thu, 22 Nov 2012 21:04:02 -0700 Message-ID: <1353643442.69940.45.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 04:04:39 -0000 --=-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--