Panic in 8.1 in softclock(): mutex Giant not owned at
../../../../sys/kern/kern_mutex.c:185
John Baldwin
jhb at freebsd.org
Tue Nov 8 15:22:15 UTC 2011
On Sunday, November 06, 2011 6:49:43 pm Vijay Singh wrote:
> Hackers. I am hitting a panic on 8.1 in the softclock() code. Anyone seen
this?
>
> PANIC : mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185
>
> (kgdb-amd64-6.8-71) bt
> #0 breakpoint () at ./machine/cpufunc.h:64
> #1 0xffffffff803d8b82 in kdb_enter (why=0xffffffff806ca339 "panic",
> msg=0xffffffff806ca339 "panic") at ../../../../sys/kern/subr_kdb.c:365
> #2 0xffffffff8039adf0 in panic (fmt=0xffffffff806c82d3 "mutex %s not
> owned at %s:%d") at ../../../../sys/kern/kern_shutdown.c:950
> #3 0xffffffff80386b2e in _mtx_assert (m=0xffffffff80c8ed40, what=20,
> file=0xffffffff806c7d18 "../../../../sys/kern/kern_mutex.c", line=185)
> at ../../../../sys/kern/kern_mutex.c:827
> #4 0xffffffff8038528e in unlock_mtx (lock=0xffffffff80c8ed40) at
> ../../../../sys/kern/kern_mutex.c:185
> #5 0xffffffff803b73e6 in softclock (arg=0xffffffff80c90f40) at
> ../../../../sys/kern/kern_timeout.c:461
> #6 0xffffffff8036436c in intr_event_execute_handlers
> (p=0xffffff000413a000, ie=0xffffff000414ad00) at
> ../../../../sys/kern/kern_intr.c:1244
> #7 0xffffffff80364443 in ithread_execute_handlers
> (p=0xffffff000413a000, ie=0xffffff000414ad00) at
> ../../../../sys/kern/kern_intr.c:1257
> #8 0xffffffff8036469f in ithread_loop (arg=0xffffff00021e92e0) at
> ../../../../sys/kern/kern_intr.c:1342
> #9 0xffffffff80361d06 in fork_exit (callout=0xffffffff80364590
> <ithread_loop>, arg=0xffffff00021e92e0, frame=0xffffff80001e7c80) at
> ../../../../sys/kern/kern_fork.c:892
> #10 <signal handler called>
>
> (kgdb-amd64-6.8-71) f 5
> #5 0xffffffff803b73e6 in softclock (arg=0xffffffff80c90f40) at
> ../../../../sys/kern/kern_timeout.c:461
> 461 class->lc_unlock(c_lock);
> (kgdb-amd64-6.8-71) l
> 456 lastfunc = c_func;
> 457 }
> 458 #endif
> 459 CTR1(KTR_CALLOUT, "callout %p finished", c);
> 460 if ((c_flags & CALLOUT_RETURNUNLOCKED) == 0)
> 461 class->lc_unlock(c_lock);
> 462 skip:
> 463 CC_LOCK(cc);
> 464 /*
> 465 * If the current callout is locally
> (kgdb-amd64-6.8-71) i local
> c_func = (void (*)(void *)) 0xffffffff8060d550 <atkbd_timeout>
You'll need to see if there is a way that this routine can drop the lock. If
you can reproduce this panic easily, then perhaps try building with KTR and
KTR_LOCK traces enabled and use 'show ktr' in ddb to see when this thread
dropped Giant.
--
John Baldwin
More information about the freebsd-hackers
mailing list