Date: Sun, 24 Mar 2013 14:57:56 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: Preemption on MV78100 (ARMv5TE)? Message-ID: <CAJ-Vmo=ZLeLvRRCtWhZ-GfnONXJK6RVJhXN=3krRUfJHt1cMkg@mail.gmail.com> In-Reply-To: <1364152536.1157.173.camel@revolution.hippie.lan> References: <1364062508310-5798411.post@n5.nabble.com> <1364063575.1157.155.camel@revolution.hippie.lan> <1364150036396-5798701.post@n5.nabble.com> <1364152536.1157.173.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Are you able to sneak this stuff into releng-8? Adrian On 24 March 2013 12:15, Ian Lepore <ian@freebsd.org> wrote: > 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 > > > _______________________________________________ > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=ZLeLvRRCtWhZ-GfnONXJK6RVJhXN=3krRUfJHt1cMkg>