On Mon, Apr 09, 2007 at 12:00:05PM +0200, Gert Doering wrote:
> Hi,
> 
> On Sun, Apr 08, 2007 at 04:16:14PM +0200, Gert Doering wrote:
> > ------------ snip ------------
> > panic: vref used where vget required, vp 0xca8d2f0
> > Begin traceback...
> > End traceback...
> > ------------ snip ------------
> 
> soooo... tried again with ddb.onpanic=1.
> 
> Panic occurs after about 30 minutes, and this is what "trace" gives me:
> 
> panic: vref used where vget required, vp 0xc9ea080
> cpu0: kdb breakpoint at 12cf900
> Stopped in pid 610.1 (uux) at   netbsd:cpu_Debugger+0x4:        nop
> vref(c9ea080, a, 3f7, d4f7c78, d4f4000, bea8c00) at netbsd:vref+0x28
> namei(0, 186a000, d00e020, d4f7c90, d4f7c48, 1) at netbsd:namei+0xb4
> vn_open(d4f7c48, 8203, 180, 1, 22, 28) at netbsd:vn_open+0x30
> sys_open(0, d4f7dc0, d4f7e00, 40500000, 4021e200, 180fef8) at netbsd:sys_open+0x
> 90
> syscall_plain(d4f7ed0, 3, 405311ec, 405311f0, 0, d4f7dc0) at netbsd:syscall_plai
> n+0x120
> ?(21a190, 8202, 180, 12830, 217b38, 22a800) at 0x1008c90
> 
> - is this enough to figure out where it is doing weird things?
> 
> 
> If I try to understand the namei() source in kern/vfs_lookup.c, it's
> not exactly clear to me what it's complaining about - there are many calls
> to a function "VREF()", but they can't all be wrong??!?

If you have a `netbsd.gdb' of this kernel you could try to locate the
VREF with gdb `list *(namei+0xb4)'.

From ddb the output of `show vnode /f 0x????????' could help.

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)