Date: Wed, 15 Feb 2012 19:20:35 -0800 From: Vijay Singh <vijju.singh@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185 Message-ID: <CALCNsJRVsuRxX6u_oOqymBGhSjCe7EwihiT88PGaiWQbOZ_TxQ@mail.gmail.com> In-Reply-To: <201111081005.43851.jhb@freebsd.org> References: <CALCNsJQEyr17UN6f7bz=6Qqs6=j_Otdk66NhUh8HbtbyvacT=Q@mail.gmail.com> <201111081005.43851.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi John,
>> (kgdb-amd64-6.8-71) f 5
>> #5 =A00xffffffff803b73e6 in softclock (arg=3D0xffffffff80c90f40) at
>> ../../../../sys/kern/kern_timeout.c:461
>> 461 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 class->lc_unlock(c_lock);
>> (kgdb-amd64-6.8-71) l
>> 456 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 lastfunc =3D c_func;
>> 457 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
}
>> 458 =A0 #endif
>> 459 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
CTR1(KTR_CALLOUT, "callout %p finished", c);
>> 460 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
if ((c_flags & CALLOUT_RETURNUNLOCKED) =3D=3D 0)
>> 461 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 class->lc_unlock(c_lock);
>> 462 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 skip:
>> 463 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
CC_LOCK(cc);
>> 464 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
/*
>> 465 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0* If the current callout is locally
>> (kgdb-amd64-6.8-71) i local
>> c_func =3D (void (*)(void *)) 0xffffffff8060d550 <atkbd_timeout>
>
> You'll need to see if there is a way that this routine can drop the lock.=
=A0If
> you can reproduce this panic easily, then perhaps try building with KTR a=
nd
> KTR_LOCK traces enabled and use 'show ktr' in ddb to see when this thread
> dropped Giant.
An update. I haven't been able to enable KTR in my environment.
However I found some interesting.
In the code below:
(kgdb-amd64-6.8-48) l
402 if (c_lock !=3D NULL) {
403 if (c_lock =3D=3D &Giant.lock_object) {
404 mtx_lock(&Giant);
405 mtx_assert(&Giant, MA_OWNED);
406 } else {
407 class->lc_lock(c_lock, sharedlock);
408 }
I hit the assert in line 405. So right after locking Giant, it is
found unlocked!!!
Everytime this hits, I see that kldload is running on the other CPU:
(kgdb-amd64-6.8-48) show_ps_running
CPU ticks pri thread tid pid
state VSZ RSS cmd
0 2 52 0xffffff000424c800 100006 11 TDS_RUNNING
0K 0K [intr]
1 3 76 0xffffff0004618400 100065 1481 TDS_RUNNING
3808K 760K kldload
Reporting it here to see if someone has seen this before.
-vijay
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALCNsJRVsuRxX6u_oOqymBGhSjCe7EwihiT88PGaiWQbOZ_TxQ>