DragonFlyBSD

:Hello.
:I caught this panic while playing with firefox-2.0.0.1 (linux binary)
:and flash9 plugin. The panic was triggered by /bin/ls (not
:/compat/linux/bin/ls), after firefox crashed. I don't use any filesystems
:other than ufs (not even /proc), yet the trace involves vop_compat_nresolve.
:
:I did `fsck fy' before this panic, so I believe this is not a panic-long
:after-an-incomplete-fsck problem.
:
:Regards.

Could you upload the coredump to leaf?

This panic occurs when a vnode has no associated VM object.  VM objects
    used to be optional but are now mandatory, so there must have been a
    path where the vnode was created without a VM object (possibly before
    the ls).  Examining the vnode might give me a clue as to how that
    happened.

-Matt

Done, saved as ~y0netan1/crash/panic-11.tar.gz . The source code
is as of just before my last commit to /sys/dev/acpica5/acpi.c (rev 1.30).

Regards.

:...
:> :Regards.
:>
:> Could you upload the coredump to leaf?
:>
:> This panic occurs when a vnode has no associated VM object. VM objects
:> used to be optional but are now mandatory, so there must have been a
:> path where the vnode was created without a VM object (possibly before
:> the ls). Examining the vnode might give me a clue as to how that
:> happened.
:
:Done, saved as ~y0netan1/crash/panic-11.tar.gz . The source code
:is as of just before my last commit to /sys/dev/acpica5/acpi.c (rev 1.30).
:
:Regards.

Hmm.  Something very odd is going on here.  It is trying to resolve
    the filename "firefox-2.0.0.1" at this path:

frame 9
    print ap->a_nch->ncp->nc_name            ("firefox-2.0.0.1")
    print ap->a_nch->ncp->nc_parent->nc_name    ("firefox")
    print *ap->a_nch->mount                ("/u")

So the path is:

"/u/firefox/firefox-2.0.0.1"

The problem is that /u/firefox seems to be a softlink.  At least,
    the vnode is marked as being a softlink and that makes the
    namecache entry illegal because it must be a directory (the namecache
    represents the 'real' path, not paths through softlinks).

The kernel then treats the vnode as a directory even though it is
    a VLNK, tries to do a block lookup on it, and panics.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

I need to look at the directory to make sure (it's not here with me now),
but I believe /u/firefox is a symlink which points to firefox-2.0.0.1,
and the link doesn't contain a slash; i.e. I did the following to create
the symlink:

1. cd /u && ln -s firefox-2.0.0.1 firefox

I use "/u/firefox/firefox" to start this linux version. I don't use chroot
to use any linux binaries.

Regards.

I've been unable to reproduce this for more than a year,
and I think this was caused by leftover from kernel crash.