Re: Kernel panic on fs mkmount

Sigh, sorry, this is one of the things fixed in my patchcluster that I
never seem to get around to striping out, cleaning up, and sending in.

The "problem" is that mkmount is a symlink (any symlink creation in AFS
will panic FreeBSD).  Specifically FreeBSD expects that upon creation of
a symlink the VP of the link and the VP of the parent are returned to
the syscall level.  My _hack_  ( a nasty one), is to call vref() on the
link itself and pass it back as _both_ the linkvp and the directoryvp. 
Since the only thing that that the syscall layer does is to vrele() the
directory pointer, and link pointer it is "safe".  The MAJOR caveat is
that if this behaviour changes _OR_ there is something else, other than
a syscall that calls VOP_SYMLINK and doesn't behave the EXACT same way
you panic (but you would panic at that location, so it is easy to
"fix".)  I grepped the source and I do not see any CURRENT situations of
this.

On Fri, 2003-05-16 at 11:44, Richard Jones wrote:
> Hi,
> 
> I'm getting a kernel panic whenever I try and "fs mkmount".
> 
> for example:
> 
> # vos create daedalus.jonze.com /vicepa usr
> # fs mkmount -dir /afs/.jonze.com/usr -vol usr
> 
> I was asked for a stack trace on the openafs-info list. I've never tried
> to debug anything before[1] let alone a kernel dump, so I had a look at
> the developers handbook, compiled a debug kernel and managed to produce
> a kernel.0 and vmcore.0.
> 
> Then according to the handbook I did the following:
> 
> # cd /usr/src/sys/compile/DEBUG
> # gdb -k
> (kgdb) symbol-file kernel.debug
> (kgdb) exec-file /usr/local/var/crash/kernel.0
> (kgdb) core-file /usr/local/var/crash/vmcore.0
> 
> And the output is attached, but it doesn't look very useful. Can anyone
> help, can I provide any more useful information? And let me know if this
> is inappropriate for the list, previous posts seem to imply that this
> list is several orders more clueful than me :-|
> 
> Cheers,
> 
> Richard
-- 
David E. Cross