Skip site navigation (1)Skip section navigation (2)
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>