Big problem still remains with 7.2-STABLE locking up

NAKAJI Hiroyuki nakaji at jp.freebsd.org
Mon Jun 8 22:50:30 UTC 2009


I got a lockup at 3 a.m. JST, but because I'm not ready for dcons I
cannot show you guys the whole ddb session.

I put a 'bt' output of kgdb.
http://www.heimat.gr.jp/localhost/kgdbbtvmcore.0

Kernel config:

include GENERIC
ident   HEIMAT
options MSGBUF_SIZE=81920
makeoptions     DEBUG=-g
options KDB
options KDB_TRACE
options KDB_UNATTENDED
options DDB
options BREAK_TO_DEBUGGER
options QUOTA
options DEVICE_POLLING
options HZ=1000
options SW_WATCHDOG
options DEBUG_VFS_LOCKS
options INVARIANTS
options INVARIANT_SUPPORT
options WITNESS

Thanks.

P.S.
"allthreads" was not a usable command in my RELENG_7's ddb.

>>>>> In <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b at mail.gmail.com> 
>>>>>	Attilio Rao <attilio at FreeBSD.ORG> wrote:

> Anyways, the only one way we have to debug this is getting some help
> by the user.
> 1) Drop the option WITNESS_SPIKSPIN (as we would like to debug
> spinlocks too) and LOCK_PROFILING (in order to create higher
> contention and kill some barriers)
> 2) Once you get the deadlock break in the DDB debugger
> 3) Once you are in DDB informations which could be very useful are:
db> show allpcpu
db> show alllocks
db> show lockedvnods
db> ps
db> allthreads

> Note that this is a lot of printout so you won't be able of collecting
> all these informations if not with a serial connection.
> 4) Dump the content so that we can further look at locks structure
> states once we identify something useful (ideally, keeping the machine
> up in DDB for that would be very useful, but often not viable)

> Let me know.
> Attilio
-- 
NAKAJI Hiroyuki


More information about the freebsd-stable mailing list