From owner-freebsd-arm@FreeBSD.ORG Sun Jan 12 06:01:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0A30357; Sun, 12 Jan 2014 06:01:34 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88F3D1775; Sun, 12 Jan 2014 06:01:34 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id bj1so2573430pad.36 for ; Sat, 11 Jan 2014 22:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=cYLrFrKrBdlOlqB/790pO2mKclbopafEBiWyv/Oli10=; b=xrK4BgJVcYlCnzJ+PJJMh4IOn5yW7N2CnVwaIwdhtXy1/9H6GVzPiDSsblL4aGasMd n6z6EORn+MJ9ywxof+55NVyKdwU2LjMvG2LrTNDPTO0XQpzrBkTRq4nBS6XmIzCF2yEd DmWvE8ab4vFBnjL8b72Az2pPyYN6FhgUfu4aOpbwTa0WfUU7/lQXgIpuffrslV/wi5iA P1StJP0OWNR+uJrQpTeX3MU/sEdDEgO1Q2O8er9wMjMuinSJvQAEnRFYPncl4P7Sxmif lumHg2dlHXv6LCrg3DHDTgS1WDGnCJRdPmOWehRJ1OcbVA5Jd1fBiV8ws97NMiI2JaJ/ hvHA== X-Received: by 10.66.43.135 with SMTP id w7mr21828593pal.97.1389506494233; Sat, 11 Jan 2014 22:01:34 -0800 (PST) Received: from [10.0.0.116] (76-244-36-134.lightspeed.sntcca.sbcglobal.net. [76.244.36.134]) by mx.google.com with ESMTPSA id vn10sm28615812pbc.21.2014.01.11.22.01.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 Jan 2014 22:01:32 -0800 (PST) References: <1382734990.1170.132.camel@revolution.hippie.lan> <1382738462.1170.153.camel@revolution.hippie.lan> <1389153310.1158.349.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: <1389153310.1158.349.camel@revolution.hippie.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <71A23BDB-671B-4D66-84C5-23A978CF8BA9@gmail.com> X-Mailer: iPad Mail (11B554a) From: Steve Subject: Re: Dreamplug stable/10 usb - sd file transfer corruption error - cache related? Date: Sat, 11 Jan 2014 22:01:34 -0800 To: Ian Lepore Cc: "freebsd-arm@FreeBSD.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 06:01:34 -0000 Ian, Thanks for testing this out on your setup. Given that you can't reproduce t= he problem, I guess it's either a bug that's been eliminated from the 10 sta= ble branch over the last few months, or some specific problem with my hardwa= re (maybe driver issue specific to my thumb drive). If I get a chance to re= visit this and get any useful data out of it I'll let you know. - Steven Sent from my iPad > On Jan 7, 2014, at 7:55 PM, Ian Lepore wrote: >=20 > Oddly enough, I never forgot about this, I just never got to it until > today. I put a concerted effort into getting data corruption on > usb->usb copying of files and even entire filesystems, and couldn't get > a glitch. I used the external sdcard (da1) and a thumb drive. I used > 'mtree -ck md5' on both source and destination, then diff'd the results, > and the files were all identical. >=20 > I tested with 11-current (@r260393) and 10-stable (@r260394) on my > DreamPlug, compiled with clang-eabi in both cases. >=20 > -- Ian >=20 >> On Fri, 2013-10-25 at 18:40 -0700, Steven Lee wrote: >> Ian, thanks for taking a look to see if you can recreate the problem. In= >> case it makes any difference in behavior, the >> command I used for the transfer was: >>=20 >> (dump -0Lf - /) | (cd /mnt/flash_root ; restore -rf -) >>=20 >> with /dev/da2s2 mounted at / and /dev/da0s2 mounted at /mnt/flash_root >>=20 >> Regards, >>=20 >> Steve >>> On Fri, Oct 25, 2013 at 3:01 PM, Ian Lepore wrote: >>>=20 >>> That old advice was based on bugs in old code that has been fixed. I've= >>> just been double-checking that the various fixes are in 10 (some of them= >>> were things I submitted a PR for before I became a committer). I'm not >>> sure about the usb driver, but there have been big changes in the dma >>> cache coherency code between 9 and 10, although much of that is the >>> fixes I was alluding to. >>>=20 >>> Basically what you're doing is a usb->usb copy, I'll see if I can >>> recreate the corruption on my dreamplug here the same way. >>>=20 >>> -- Ian >>>=20 >>>> On Fri, 2013-10-25 at 14:38 -0700, Steven Lee wrote: >>>> ---------- Forwarded message ---------- >>>> From: Steven Lee >>>> Date: Fri, Oct 25, 2013 at 2:37 PM >>>> Subject: Re: Dreamplug stable/10 usb - sd file transfer corruption erro= r >>> - >>>> cache related? >>>> To: Ian Lepore >>>>=20 >>>>=20 >>>> Ian, thanks for your reply. >>>>=20 >>>> I am using the DREAMPLUG-1001 stock kernel config, and you are right th= e >>>> internal sd card shows up as a usb device, /dev/da0. >>>>=20 >>>> As I mentioned, I tried modifying pmap.c as per one of your suggestions= >>> to >>>> an earlier poster / problem, but it didn't seem to help the issue. I >>>> changed the pmap_pte_init_arm10() function to look like the >>>> pmap_pte_init_arm9() function. >>>>=20 >>>> Any other thoughts about things to try? Since it seems like this is a >>>> regression between 9 and 10, are you aware of any specific cache relate= d >>>> changes to the usb driver between the branches? >>>>=20 >>>> - Steve >>>>=20 >>>>=20 >>>>> On Fri, Oct 25, 2013 at 2:03 PM, Ian Lepore wrote: >>>>>=20 >>>>>> On Fri, 2013-10-25 at 13:37 -0700, Steven Lee wrote: >>>>>> Hello, >>>>>>=20 >>>>>> 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: >>>>>>=20 >>>>>> 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 >>>>>>=20 >>>>>> There are no problems that show up to this point, the Dreamplug boots= >>>>> with >>>>>> no errors. >>>>>>=20 >>>>>> 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) >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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 >>>>>>=20 >>>>>> but all of these attempts were ineffective. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Thanks for your help! >>>>>>=20 >>>>>> Regards, >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Are you using the stock kernel config (DREAMPLUG-1001)? If not, have >>>>> you got "option USB_HOST_ALIGN=3D32" in your kernel config? >>>>>=20 >>>>> 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). >>>>>=20 >>>>> -- Ian >>>> _______________________________________________ >>>> freebsd-arm@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20