Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185

[John Baldwin]

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