I'm running 4.6.5 on FreeBSD 2.2.6, with a kernel that includes KAME
and lots of local hacking.

My machine crashed recently, under heavy general use but I believe no
particular use of Coda (ie make install in local filesystems, etc.).
I didn't get a clean crash dump, but I got this much:

 fnord root 11 /var/crash #> !gd
 gdb -k kernel.4 vmcore.4
 GDB is free software and you are welcome to distribute copies of it
  under certain conditions; type "show copying" to see the conditions.
 There is absolutely no warranty for GDB; type "show warranty" for details.
 GDB 4.16 (i386-unknown-freebsd), 
 Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...
 IdlePTD 25d000
 current pcb at 238414
 panic: nbsd_vop_error
 #0  0xf011aab3 in boot ()
 (kgdb)

After a little reading, I see that nbsd_vop_error is called whenever a
VOP comes down to the cfs for which there is no real implementation,
although I wonder if something is supposed to trap these higher in the
call chain.

I then went to my crash&burn machine and ran, in a coda directory, as
root

  mknod foo c 1 0

Which produced the following kernel stack backtrace:

 ti5 root 5 /var/crash #> gdb -k kernel.1 vmcore.1 
 GDB is free software and you are welcome to distribute copies of it
  under certain conditions; type "show copying" to see the conditions.
 There is absolutely no warranty for GDB; type "show warranty" for details.
 GDB 4.16 (i386-unknown-freebsd), 
 Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...
 IdlePTD 281000
 current pcb at 231c40
 panic: nbsd_vop_error
 #0  0xf011e6b7 in boot ()
 (kgdb) bt
 #0  0xf011e6b7 in boot ()
 #1  0xf011e993 in panic ()
 #2  0xf0105832 in nbsd_vop_error ()
 #3  0xf013d709 in mknod ()
 #4  0xf01e7ad7 in syscall ()
 #5  0x1655 in ?? ()
 #6  0x107e in ?? ()
 (kgdb) q

Unfortunately, I don't know which VOP caused the first panic (the one
that happened when I wasn't trying to push things).  I'm tempted to
make cfs/cfs_vnodeops.c:nbsd_vop_error return EOPNOTSUPP
instead of panicing, as it seems like many of the operations are
something someone could reasonably try.

Any comments?

        Greg Troxel <gdt_at_ir.bbn.com>