Date: Tue, 16 Jul 2002 07:30:57 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: des@ofug.org Cc: gallatin@cs.duke.edu, current@FreeBSD.ORG Subject: Re: VOP_GETATTR panic on Alpha Message-ID: <200207161431.g6GEUvwr027315@gw.catspoiler.org> In-Reply-To: <xzpznwr2383.fsf@flood.ping.uio.no>
index | next in thread | previous in thread | raw e-mail
On 16 Jul, Dag-Erling Smorgrav wrote:
> Andrew Gallatin <gallatin@cs.duke.edu> writes:
>> Just clear panicstr (w panicstr 0) when you drop into
>> the debugger on a panic.
>
> No luck. However, I added an ASSERT_VOP_LOCKED() to vn_statfile(),
> and confirmed that vn_lock() fails to lock the vnode. Unfortunately,
> without a dump it's hard to tell exactly what kind of vnode we're
> dealing with.
>
> I thought the problem might be an incorrect vop_lock implementation in
> devfs (the only synthetic filesystem mounted on the box), but devfs
> uses std_{islocked,lock,unlock}, and visual inspection didn't uncover
> any obvious flaws in any of those.
>
> Any other suggestions before I just turn off DEBUG_VFS_LOCKS?
Turn it off. I ran into similar problems about a week ago and the
author told me that this option was broken because only part of the
stuff in his private source tree was committed. I haven't heard
anything since then to make me think that this option has been fixed.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207161431.g6GEUvwr027315>