Date: Sun, 24 Mar 2013 13:15:36 -0600 From: Ian Lepore <ian@FreeBSD.org> To: MagnusNilsson <magnus.nilsson@gmail.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: Preemption on MV78100 (ARMv5TE)? Message-ID: <1364152536.1157.173.camel@revolution.hippie.lan> In-Reply-To: <1364150036396-5798701.post@n5.nabble.com> References: <1364062508310-5798411.post@n5.nabble.com> <1364063575.1157.155.camel@revolution.hippie.lan> <1364150036396-5798701.post@n5.nabble.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-CdVGYqnbm3oYVwVwPIDn Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, 2013-03-24 at 11:33 -0700, MagnusNilsson wrote: > > Can you provide any information about the crashes? > Sorry, "crash" is misleading. Rather, it hangs, almost always during boot. > The latest hangs I saw where at "Entropy harvesting:[hang]" and "Trying to > mount root from ufs:/dev/ad0s1[hang]" > I have tried both SCHED_4BSD and SCHED_ULE, but I don't see any difference. > > > something to try that may give you most of the same benefits would be to > > compile with HZ=1000 > Thanks, HZ=2000 already. I mainly want to ensure that the crash isn't caused > by some other instability that is tickled by preemption. Basically I want it > working - or I want to know why it doesn't. > > These two patches are applied, but with no improvement: > http://www.freebsd.org/cgi/query-pr.cgi?pr=arm/160431 > http://www.freebsd.org/cgi/query-pr.cgi?pr=arm/161498 > I'll see if I can backport later fixes to 8.2 and see if that helps. Damn, I was putting my hopes on the RAS fix, and you've already got it. Oh yeah, here's another fix that isn't in 8.2 that's pretty important, at least on kirkwood series chips... Enabling cache write-allocate causes data corruption. The attached patch should be the one that applies cleanly to 8.2. The following is from an email I wrote to a coworker some time ago about this patch and how I was testing with it... I think the attached patch may be the fix for the random 32-byte corruption problem you've been seeing on dreamplug. It certainly fixes such a problem on mine. For testing this, I found that the problem was 100% recreatable. I created a 10MB file full of zeroes and put it in the directory I tftp-boot from. To test: cd /tmp ; echo get zeroes | tftp revolution ; hd zeroes | head -30 To automate that test, I put the above into a script name 't' and do: while true ; do t | wc -l | grep -q 5 || break ; done A good run where the file comes in as all-zeroes always gives 5 lines of output. With the attached patch in place, I can run this for hours. While testing, it helps if some other things are going on, things that cause process context switches, while the tftp is running. From another window on my build machine I run this continuously: while true ; do ssh root@dpcur fsck -n -t ufs /var ; sleep 1 ; done I dunno if fsck is magical, but I did notice that because I always reboot and test, bg fsck is often running while I'm testing, and the corrupted fragments in the zeroes file are often bits of strings that fsck says. But I suspect what's really important is that other processes and context switches are running during the file xfer. -- Ian --=-CdVGYqnbm3oYVwVwPIDn Content-Disposition: inline; filename="dp_cache_wralloc.diff" Content-Type: text/x-patch; name="dp_cache_wralloc.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Do not enable allocating a cache line on write access. Instead, leave that feature in whatever state the bootloader set it to, on the theory that the firmware that comes with the unit knows best. This fixes intermittant cache line corruptions during bulk network data flow. diff -r df572d6d53cd -r a142512ee876 sys/arm/arm/cpufunc.c --- sys/arm/arm/cpufunc.c Thu Nov 22 16:46:06 2012 -0700 +++ sys/arm/arm/cpufunc.c Sat Dec 01 15:38:59 2012 -0700 @@ -1067,13 +1067,13 @@ set_cpufuncs() */ if (cputype == CPU_ID_MV88FR571_VD || cputype == CPU_ID_MV88FR571_41) { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN | FC_L2_PREF_DIS); } else { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN); } --=-CdVGYqnbm3oYVwVwPIDn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1364152536.1157.173.camel>