Re: panic: mutex Giant not owned at /usr/src/sys/cam/cam_xpt.c:4837

Robert Watson wrote:
> 
> On Wed, 26 Apr 2006, Anish Mistry wrote:
> 
>> #10 0xc04cc002 in panic (fmt=0xc06284f9 "mutex %s not owned at %s:%d")
>>    at /usr/src/sys/kern/kern_shutdown.c:549
>> #11 0xc04c3b43 in _mtx_assert (m=0xc06286ff, what=-1056878592,
>>    file=0xc06181c9 "/usr/src/sys/cam/cam_xpt.c", line=4837)
>>    at /usr/src/sys/kern/kern_mutex.c:768
>> ---Type <return> to continue, or q <return> to quit---
>> #12 0xc0432c65 in xpt_release_devq (path=0x0, count=1, run_queue=1)
>>    at /usr/src/sys/cam/cam_xpt.c:4837
>> #13 0xc043420e in xpt_action (start_ccb=0xc22f9530)
>>    at /usr/src/sys/cam/cam_xpt.c:3580
>> #14 0xc051091b in kern_sendit (td=0xc28f7870, s=4, mp=0xcca4bc6c,
>> flags=0,
>>    control=0x0, segflg=3227694719)
>> at /usr/src/sys/kern/uipc_syscalls.c:775
>> #15 0xc0511965 in sendit (td=0xc28f7870, s=4, mp=0xcca4bc6c, flags=0)
>>    at /usr/src/sys/kern/uipc_syscalls.c:715
> 
> 
> Something really nasty happened to the stack between frame 14 and frame 
> 13. The above code path Should Never Happen.  The CAM bit is consistent 
> with itself, and with the panic message, and the socket bit is 
> consistent with itself.  That leaves a question about what happened in 
> between.  Did you try running 'trace' under DDB?  If so, can you use 
> dmesg on the core dump to see if the DDB trace differs from the gdb trace?
> 
> Robert N M Watson

There are quite a few missing frames from CAM-land.

Scott