Date: Mon, 12 Nov 2012 13:13:09 -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: <1352751189.1217.50.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
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. > > Here is a dmesg from this machine. Note the interrupt storm on intr21, that's the eSATA drive. > > [dmesg snipped] I remember testing the eSata, trying to reproduce a problem someone (maybe mav@) reported here a few months ago. I don't remember seeing the interrupt storm but I could have overlooked it. I did get the sata drive (an SSD drive) to work and I used dd to read and write the drive. The report of problems involved intermittant corruptions of 32 byte blocks (which sounds a whole lot like a cacheline flush problem). I was trying to dd from /dev/zero to the drive and then read it back and look for any non-zero data, and I never saw any glitched blocks. It suddenly occurs to me that I was reading/writing the raw unpartitioned device. I wonder if the problem for some reason only shows up when you do filesystem access? It might be interesting for you to try a basic IO test such as dd if=/dev/zero of=/some_file bs=1m count=10 then dd if=/some_file bs=1m | hd -C and you should see output from hd that summarizes that everything was the same as the first line (zeroes), or if there are glitches they'll show as additional lines of output from hd. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1352751189.1217.50.camel>