panic: mutex Giant not owned at /usr/src/sys/cam/cam_xpt.c:4837
Scott Long
scottl at samsco.org
Wed Apr 26 10:31:17 UTC 2006
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
More information about the freebsd-current
mailing list