NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: misc/43182: Reboot due to system crash
The following reply was made to PR kern/43182; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc:
Subject: Re: misc/43182: Reboot due to system crash
Date: Sat, 24 Apr 2010 02:32:21 +0000
On Fri, Apr 23, 2010 at 07:45:01AM +0000, Fr?d?ric Fauberteau wrote:
> In case (1) c03b0ea5 is between :
> c03b0e70 T ext2fs_inactive
> c03b0fc0 T ext2fs_checkpath
For this to happen ext2fs_inactive would have to be passed either a
null vnode, a vnode with a null inode attached to it, or a vnode with
a null v_mount. In theory, none of these should happen, even on error,
so if you can get a stack trace from ddb or from a crashdump it might
be useful.
> In case (2) c046a188 is between :
> c046a1d0 T kpsignal
> c046a270 T kpgsignal
no it isn't, a188 < a1d0... but, since you have a trace:
> My USB disk was mounted is ext2fs. I has umounted it but my kernel
> continue to panic. In ddb mode, I obtained this trace :
>
>
kpsignal2(cc552cf4,cad21d04,cad21d04,cbd41a5c,cc552cf4,cad21d24,cad21d40,c0476cd9,cc552cf4,cad21d04)
> at netbsd:kpsignal2+0x5a8
> kpsignal(cc552cf4,cad21d04,0,10c,10c,cad21d04,cad21d40,0,0,0) at
> netbsd:kpsignal+0x7a
>
timer_intr(0,ca920010,ca920030,cad20010,ca920010,0,a3d360,c16b0400,0,cad21da0)
> at netbsd:timer_intr+0x229
I don't see how this can be the same problem. Does this one continue
to happen if you boot the machine without the USB device and don't
insert it? Is there anything that seems to cause it or that it seems
to be related to doing?
> but I don't know if it is usefull ... I don't know why, but the dump of
> the kernel fails (nothin in /var/crash except 'minfree' file).
The most common reason is that the swap device isn't big enough to
hold the dump image. There's a newish feature for writing small dumps
but I'm not sure if it's in 5.0.2.
> I have compile my kernel from sources. Now I'm waiting for a panic and I
> know that nm is my friend ;)
If you've done that, ddb is usually more your friend... although the
nm -n technique is still sometimes useful. (objdump -d /netbsd can be
useful too sometimes if one isn't afraid of wading through assembly
code.)
There's also some chance that if you build a kernel from the netbsd-5
branch (5.0_STABLE, what will eventually become 5.1) either or both of
these problems will go away. The 5.0.x releases (netbsd-5-0 branch)
only get critical fixes.
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index