Re: Current panics

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sat, Nov 21, 2009 at 03:06:05AM +0300, Aleksej Saushev wrote:
> Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:
> 
> > On Fri, Nov 20, 2009 at 09:57:01PM +0100, Manuel Bouyer wrote:
> >> On Fri, Nov 20, 2009 at 08:54:00PM +0300, Aleksej Saushev wrote:
> >> > Is there any way to associate addresses to line numbers?
> >> 
> >> The only way I know is with gdb, but this needs a kernel compiled with -g.
> 
> > Wit the right kenrel config file I get:
> > (gdb) l *(vn_open+320)
> > 0xc0462edd is in vn_open (/home/bouyer/HEAD/src/sys/kern/vfs_vnops.c:159).
> > 154                             ndp->ni_cnd.cn_flags |= FOLLOW;
> > 155             }
> > 156     
> > 157             VERIEXEC_PATH_GET(ndp->ni_dirp, ndp->ni_segflg, 
> > ndp->ni_dirp, path);
> > 158     
> > 159             error = namei(ndp);
> > 160             if (error)
> > 161                     goto out;
> > 162     
> > 163             vp = ndp->ni_vp;
> >
> > So it could be in namei(). If you still have your netbsd.gdb around
> > could you confirm it (in my binary the address don't match exactly to
> > what you reported) ?
> 
> Unfortunatly, I don't have it. This is the importance of having clear
> documentation what data are necessary for troubleshooting, if I knew
> it in the morning, I'd preserve this file. (Why not install it to "/"?
> To "/var/something"? For debug kernels it is reasonable. At least, some
> knob to do it might be useful.)

Well, it's big and not so usefull without the source tree from which it
was built ...

> 
> The kernel in consideration is built with -g (it isn't the first one in
> this crashing series). Is it useful somehow without .gdb?

I don't think as it has been stripped.

> I don't have enough gdb skills, can you point to more extensive cheat
> sheet or provide instructions? (I remember there were some on the web
> site, but they were out of date past summer.)
> 
> > namei() does a VREF which is atomic_inc_uint(&vp->v_usecount).
> > I guess vp is NULL; extracting dmesg
> > from the core dump to get the fault address could confirm it.
> 
> Do you mean this?
> 
> $ dmesg -M netbsd.43.core -N netbsd.43
> dmesg: kvm_read: Undefined error: 0
> dmesg: kvm_read: 
> 

Since the tools on a live system have been moved away from kmem
groveling, kvm support if broken and gets unoticed. That's unfortunate;
I don't know if some regression tests could be written for that ?

> 
> $ crash -M netbsd.43.core -N netbsd.43
> Crash version 5.99.22, image version 5.99.22.
> System panicked: dump forced via kernel debugger
> Backtrace from time of crash is available.
> crash> dmesg 1024
> 
> ...
> 
> /home: replaying log to disk
> i915drm0: interrupting at ioapic0 pin 16
> uvm_fault(0xe552b0e4, 0, 2) -> 0xe
> fatal page fault in supervisor mode
> trap type 6 code 2 eip c04a62b4 cs 8 eflags 210206 cr2 14 ilevel 0

Ok, the fauling address is 0x14. 
(gdb) print/x &((struct vnode *)0)->v_uobj.uo_refs
$1 = 0x14

So this is another hint that the issue is with a NULL vnode.
Why it's NULL, this I don't know. 

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--