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

On Wed, 26 Apr 2006, Scott Long wrote:

> 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?
>
> There are quite a few missing frames from CAM-land.

I'm sort of vaguely hoping that DDB will give a better stack trace, but I'm 
not sure there's much hope.  It seems like perhaps the stack has gotten quite 
hosed.

I guess the missing CAM frames couldn't be put down to inlined frames not 
showing up in DDB?  It sort of looks like we have the top of one stack, and 
the bottom of another stack.  Until you get to kern_Sendit(), it all sounds 
pretty good from the system call perspective.  It would be interesting to look 
higher up the thread and confirm whether this system call is, in fact, 
sendto() or something along those lines.

Robert N M Watson