Big problem still remains with 7.2-STABLE locking up

NAKAJI Hiroyuki nakaji at jp.freebsd.org
Sat Jun 6 16:29:00 UTC 2009


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

> > The kernel configuration is:
> >
> > include GENERIC
> > ident   HEIMAT
> > options MSGBUF_SIZE=81920
> > makeoptions     DEBUG=-g
> > options KDB
> > options DDB
> > options BREAK_TO_DEBUGGER
> > options QUOTA

> Were you unmounting any of the QUOTA'ed filesystems?

No. Quota'ed file system is /home which is not easily unmounted.

> 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)

Removed two lines from KERNCONF.

> 2) Once you get the deadlock break in the DDB debugger

Hmm. It is the most difficult: the box cannot break in the DDB debugger
for now.

> 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.

The box does not have any serial port. Is there any other way? Is it
possible to use dcons(4) for that purpose, if I add firewire PCI board?

> 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)

Thank you for instruction. I'll try.
-- 
NAKAJI Hiroyuki


More information about the freebsd-stable mailing list