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