Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Oct 2013 15:03:10 -0600
From:      Ian Lepore <ian@FreeBSD.org>
To:        Steven Lee <ssl.qlt@gmail.com>
Cc:        freebsd-arm@FreeBSD.org
Subject:   Re: Dreamplug stable/10 usb - sd file transfer corruption error - cache related?
Message-ID:  <1382734990.1170.132.camel@revolution.hippie.lan>
In-Reply-To: <CALD1=P=gWosQsTTYt=hpkasP8y1rH3oH6y0n-y=APP_X0S%2BYFQ@mail.gmail.com>
References:  <CALD1=P=gWosQsTTYt=hpkasP8y1rH3oH6y0n-y=APP_X0S%2BYFQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2013-10-25 at 13:37 -0700, Steven Lee wrote:
> Hello,
> 
> In the process of upgrading my Dreamplug from the stable/9 branch to the
> stable/10 branch, I have run into a fairly
> significant file corruption problem.  The steps that create this problem
> are as follows:
> 
> 1. Cross-compile the kernel and buildworld from the stable/10 branch on a
> separate host.
> 2. Install the kernel and installworld on a usb stick drive
> 3. Boot the Dreamplug from the usb drive
> 
> There are no problems that show up to this point, the Dreamplug boots with
> no errors.
> 
> 4. Copy the kernel from the usb drive to the internal sd card
> 5. Copy the root filesystem from the usb drive to the internal sd card
> using (dump | restore)
> 
> It is at step 5 that the error manifests itself, as I found that
> approximately 20 shell scripts in the /etc/rc.d directory
> had been randomly corrupted with strings of null characters (in groups of
> 32).  I assume that the rest of the file system
> was compromised in a similar fashion.  The bug is repeatable, however the
> corruption is somewhat random, so
> each time different files are corrupted in different places.
> 
> When I followed the exact same steps from the stable/9 branch, the problem
> did not occur, so there is clearly some
> type of regression error between the 9 and 10 branches.
> 
> After searching through the arm mailing list, I attempted to work around
> the problem by:
> - mounting the file systems with -o noclusterr -o noclusterrw
> - mounting the file systems with -o sync
> - as per comments on bug arm/158950, attempted to modify the pmap.c
> functions to change the cache from
> write-back mode to write-through mode
> 
> but all of these attempts were ineffective.
> 
> Given that I am relatively new to FreeBSD, I was hoping to get any insights
> as to any next steps that might make
> sense in terms of either working around the problem, narrowing down the
> bug, or any obvious rookie mistakes I
> am making before I give up and revert back to the 9 branch.
> 
> Thanks for your help!
> 
> Regards,

On my dreamplug (model 1001) both the internal and external sd cards are
actually usb devices (they show up as /dev/da0 and da1, not mmcsd0/1).
I'm not sure if that's true on all models or not.

Are you using the stock kernel config (DREAMPLUG-1001)?  If not, have
you got "option USB_HOST_ALIGN=32" in your kernel config?

Corruption in 32 byte chunks is almost always partial cacheline flush
problems, but I haven't seen that happen on dreamplug for a long time
(and when I did see it, it was with a sata drive).

-- Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1382734990.1170.132.camel>