>>>>> In <3bbf2fe10906060749xbbc2f2fy4c09f67711a...@mail.gmail.com> >>>>> Attilio Rao <atti...@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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
