Re: Current panics

[Aleksej Saushev <asau%inbox.ru@localhost>]

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.)

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 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: 

(It doesn't work. Why?)

$ 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

dumping to dev 0,1 offset 1592368
dump

Is it enough?

> Now I don't have much clues about how namei works, so I can't easily see if
> something is wrong with vnode locking or reference count here.


-- 
HE CE3OH...