Is this related to the general panic discussed in freebsd-current?

[Tim Kientzle]

On May 4, 2013, at 2:41 PM, Tim Kientzle wrote:

> 
> On May 3, 2013, at 6:45 AM, Werner Thie wrote:
> 
>> On 5/3/13 3:13 PM, Warner Losh wrote:
>>> On May 3, 2013, at 12:26 AM, Werner Thie wrote:
>>> 
>>>> Hi all
>>>> 
>>>> just came around yesterday to start playing with crochet, built an image and KDB entering panic when booting
>>>> 
>>>> FreeBSD 10.0-CURRENT #0 r250144M: Thu May  2 10:10:20 CEST 2013
>>>> root at xtools:/usr/home/wthie/proj/crochet-freebsd/work/obj/arm.armv6/usr/local/src/sys/BEAGLEBONE 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/local/src/sys/arm/arm/pmap-v6.c:1187
>>>> KDB: enter: panic
>>>> [ thread pid 0 tid 0 ]
>>>> Stopped at      $d:     ldrb    r15, [r15, r15, ror r15]!
> 
> I think I've managed to isolate this to the stack_capture function in sys/arm/arm/stack_machdep.c.
> 
> Here's the breadcrumb trail I've followed so far:
> 
> 1. Witness is complaining about pmap_fault_fixup trying to acquire the "pmap pv global" lock before it dies.
> 
> 2. Inserted printfs, found that pmap_fault_fixup was being called from data_abort_handler (in sys/arm/arm/trap.c).
> 
> 3. Uncommenting the printf in data_abort_handler gives the next step:
> 
>    data abort: fault address=0xe28db008 (from pc=0xc0519d08 lr=0xc0519d14)
> 
> 4. According to objdump, the PC address above is in stack_save (actually, the inlined version of stack_capture), in sys/arm/arm/stack_machdep.c.
> 
> If I add a printf() to the middle of stack_capture, the kernel boots.  So it definitely smells like a code-generation error of some sort.
> 
> I'm going to start digging through the assembly next.

I'm baffled.  If I insert a printf into the loop in stack_capture, the kernel boots.
But the generated assembly looks perfectly correct to me in either
case.  So inserting the printf must have some side-effect.

The stack does end up aligned differently:  The failing version puts 16 bytes
on the stack, the working version puts 24 bytes.  But I can't figure out how
that would explain what I'm seeing...

Tim