Re: panic: System call lstat returning with 1 locks held

2008/1/26, Scot Hetzel <swhetzel_at_gmail.com>:
> On 1/24/08, Attilio Rao <attilio_at_freebsd.org> wrote:
> > 2008/1/24, Yar Tikhiy <yar_at_freebsd.org>:
> > > On Tue, Jan 15, 2008 at 04:39:24PM +0200, Kostik Belousov wrote:
> > > >
> > > > I think this could be related to the recent vn_lock()/VOP_LOCK() KPI changes.
> > > > Please, add DEBUG_VFS_LOCKS to the kernel config, and do the
> > > >       show lockedvnods
> > > > from the ddb prompt when the panic occurs. The witness does not track
> > > > the lockmgr locks.
> > >
> > > I think I'm seeing the same panic on UFS.  It's rather nasty: I
> > > cannot rebuild CURRENT natively due to it so I have to build it
> > > under 6-STABLE.  My favourite way to trigger the panic reliably is
> > > running `make install' in a simple port directory, e.g., portmaster,
> > > but my system also panics during daily scripts run and, as already
> > > said, if trying to build world.
> >
> > Yar,
> > as it seems reproducible for you, can you please add this patch to the tree:
> > http://www.freebsd.org/~attilio/debug_tdlocks.diff
> >
> > compile your kernel with:
> > options KTR
> > options KTR_COMPILE=(KTR_SPARE2)
> > options KTR_MASK=(KTR_SPARE2)
> > options KTR_ENTRIES=32768
> >
> > and once kernel panics, at ddb prompts do:
> > > show ktr
> >
>
> I added the above options to my kernel, and performed a scripted textdump.
>
> /sbin/ddb script lockinfo="show locks; show alllocks; show lockedvnods"
> /sbin/ddb script kdb.enter.panic="textdump set; capture on; show ktr ;
> run lockinfo ; show pcpu; bt; ps; alltrace; capture off; call doadump;
> reset"
>
> After the kernel paniced, the kdb.enter.panic script ran and created a
> textdump.  When I extracted the 2.7M ddb.txt file, it didn't show any
> calls to lockmgr_disown in the ktr trace.
>
> Let me know if there is anything else that I can do.
>
> To get this dump, DB_CAPTURE_MAXBUFSIZE (sys/ddb/db_capture.c) needed
> to be increased from its default of 512K to 5M, and then setting the
> debug.ddb.capure.bufsize to 5M after rebooting with the new kernel.

Scot,
thanks a lot for your effort.

I think I will produce more patch which can help for diagnosis very
soon so that we can gather more informations and see what is the real
culprit of this.

> See PR 119993 (http://www.freebsd.org/cgi/query-pr.cgi?pr=119993)
> which adds two new kernel options to allow the capture buffer size to
> be changed at compile time.

Oh, there is a PR bugathon too, this week... :)

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein