__rw_wlock_hard panic on 1st malloc

[Warner Losh]

On Apr 18, 2013, at 2:33 AM, Damjan Marion wrote:

> 
> On Apr 18, 2013, at 10:08 AM, Andrew Turner <andrew at fubar.geek.nz> wrote:
> 
>> On Wed, 17 Apr 2013 22:36:29 -0600
>> Warner Losh <imp at bsdimp.com> wrote:
>> 
>>> 
>>> On Apr 17, 2013, at 7:36 PM, Andrew Turner wrote:
>>> 
>>>> On Wed, 17 Apr 2013 09:37:26 -0600
>>>> Warner Losh <imp at bsdimp.com> wrote:
>>>> 
>>>>> I don't think it is, at least not with clang compiled code. Ian was
>>>>> saying on IRC that he saw this and went back to gcc and life was
>>>>> good.
>>>> 
>>>> I suspect it is an issue with the newer version of clang imported
>>>> recently. I have tested with an old version of clang and an updated
>>>> kernel and had no issues booting.
>>> 
>>> If I take WITNESS out of the kernel, I have no issues either. Not
>>> sure what WITNESS' problem is...
>> 
>> I've tried with an updated clang on a PandaBoard with WITNESS enabled.
>> The only issue I'm hitting is vm_thread_new fails, but this is after
>> FreeBSD enters userland which, from you other emails, appears to be
>> further than you are getting.
>> 
>> I have set unmapped_buf_allowed = 0 in sys/arm/arm/pmap-v6.c to work
>> around the above stack issue. I don't know if this will fix the issue
>> or not but you can try it to see.
> 
> Just tried clang + unmapped_buf_allowed=0:
> 
> Copyright (c) 1992-2013 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>        The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 10.0-CURRENT #0 r+b594eb9-dirty: Thu Apr 18 09:29:34 CEST 2013
>    dmarion at vm-freebsd-head:/tmp/WANDBOARD arm
> FreeBSD clang version 3.3 (trunk 178860) 20130405
> WARNING: WITNESS option enabled, expect reduced performance.
> panic: acquiring blockable sleep lock with spinlock or critical section held (rw) pmap pv global @ /usr/src/sys/arm/arm/pmap-v6.c:1187
> KDB: enter: panic

That's where it panics for me, but tr in ddb fails to give any meaningful stack traceback. Turning off witness gets me to the mountroot> prompt.