Date: Tue, 10 Jul 2012 17:22:25 -0500 From: Alan Cox <alc@rice.edu> To: Andreas Tobler <andreast-list@fgznet.ch> Cc: alc@freebsd.org, Alan Cox <alan.l.cox@gmail.com>, Justin Hibbits <chmeeedalf@gmail.com>, freebsd-ppc@freebsd.org Subject: Re: Panic with latest pmap lock changes. Message-ID: <4FFCAB21.1040400@rice.edu> In-Reply-To: <4FFC8F40.90505@fgznet.ch> References: <20120707102004.3e874201@narn.knownspace> <4FF87446.2090903@rice.edu> <4FF9F3CF.6050608@fgznet.ch> <CAJUyCcPDLmNKaW8WTQWMMW9tx%2BL2ovYYtxj0MD94EAhT=Z2ZRQ@mail.gmail.com> <4FFC8F40.90505@fgznet.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/10/2012 3:23 PM, Andreas Tobler wrote: > On 10.07.12 22:00, Alan Cox wrote: >> On Sun, Jul 8, 2012 at 3:55 PM, Andreas Tobler <andreast-list@fgznet.ch >> <mailto:andreast-list@fgznet.ch>> wrote: >> >> On 07.07.12 19:39, Alan Cox wrote: >> >> On 07/07/2012 09:20, Justin Hibbits wrote: >> >> Looks like I spoke too soon about the pmap lock changes >> working on my >> G4. After about 24 hours of uptime, it panicked with the >> following: >> >> _rw_wlock_hard: recursing but non-recursive rw pmap pv >> global >> @ /home/chmeee/freebsd/src/sys/__powerpc/aim/mmu_oea.c:2301 >> >> I think the attached patch should fix it (Untested, >> except for >> compiling). >> >> >> Ugh. Sorry. >> >> The attached patch eliminates the lock recursion. While I >> was doing >> that, I noticed that the pmap_ts_referenced() implementations on >> powerpc >> have the wrong return type. Oddly, the comments in mmu_if.h >> have the >> return type correct, but the code two or three lines later has >> it wrong. >> >> >> Fyi, I'm building world with the patch mentioned in this thread and >> the kernel updated to 238258. (G5-SMP 32-bit) >> >> So far it looks promising. >> >> Before 238258 I got reliable machine locks/freeze w/o any idea what >> was happening. >> >> If I reverted mmu_oea.c back to 238158, one before the commit from >> you Alan, I was able to get a successful full world/kernel build >> cycle. >> Yes, I confirmed that it booted, but I was not able to run a full >> world/kernel cycle since I lost my GEOM_APM config ;). >> >> Anyway, as said, it looks promising and it will take some hours to >> complete. >> >> >> Should I commit the patch? > > Hmmm, I had three successful world/kernel builds with this patch. All > with a GENERIC kernel. But I also had one freeze, no info/panic > nothing, with a kernel where I disabled the WITNESS/INVARIANTS stuff. > > I think the patch is an improvement. I need to figure why I do not get > any info when the machine freezes/locks whatever. But this can be done > with the committed patch. Maybe we get bigger testing audience when it > is committed. > A combined effect of this and the previous patch is that there will be a little more concurrency within the VM system on 32-bit aim/oea systems. This might have exposed a race in the machine-dependent code. The state of the locking on 32-bit aim/oea systems is now comparable to i386 and sparc64, but behind amd64 and aim/oea64. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FFCAB21.1040400>