Subject: 2.0 kernel crash
To: NetBSD/Sparc64 Mailing-list <port-sparc64@netbsd.org>
From: ali (Anders Lindgren) <dat94ali@ludat.lth.se>
List: port-sparc64
Date: 12/05/2004 16:26:39
On the odd chance this is of help to anyone...
Just updated my 2.0_RC5 system to 2.0 with build.sh as per normal
procedure, installed kernel, rebooted and installed the distribution to /
and rebooted, and all seemed fine. Then I realized I should probably build
a release while I was at it, for burning a CD to bring home. To avoid
rebuilding the entire system I did a build.sh -u -M [....] tools release.
Checking back this afternoon I find the machine has:
db> bt
uvm_anfree(603c228, 11bc400, 1c68bf0, 8000000010784632, ffffffffffffffff, 1810000) at netbsd:uvm_anfree+0xb8
amap_wipeout(603c220, 0, 9, 0, 3fffff, 11cac00) at netbsd:amap_wipeout+0xf8
uvm_unmap_detach(6091e90, 0, ffffffffffffffff, 5ed7ae8, 13f, ed2) at netbsd:uvm_unmap_detach+0x160
uvmspace_free(6445740, 0, 0, 1, badcafe, badcafe) at netbsd:uvmspace_free+0xe0
exit1(6460710, 0, 40222180, ffffffffffffce68, 1, 12) at netbsd:exit1+0x308
sys_exit(0, 5ed7dd0, 5ed7dc0, 1, 9182008202, 0) at netbsd:sys_exit+0x3c
syscall(5ed7ed0, 1, 409310ec, 800, 1814800, 0) at netbsd:syscall+0x32c
?(0, 0, 11d400, 220400, 4, 1) at 0x1009614
and:
db> ps
PID PPID PGRP UID S FLAGS LWPS COMMAND WAIT
>23592 14670 1484 0 2 0x6002 1 sh
14670 1681 1484 0 2 0x4002 1 nbmake wait
1681 23999 1484 0 2 0x4002 1 sh wait
23999 14701 1484 0 2 0x4002 1 nbmake wait
14701 11820 1484 0 2 0x4002 1 sh wait
11820 4132 1484 0 2 0x4002 1 nbmake wait
4132 25721 1484 0 2 0x4002 1 sh wait
25721 3698 1484 0 2 0x4002 1 nbmake wait
3698 27792 1484 0 2 0x4002 1 sh wait
27792 27941 1484 0 2 0x4002 1 nbmake wait
27941 18746 1484 0 2 0x4002 1 sh wait
18746 1484 1484 0 2 0x4002 1 nbmake wait
1484 304 1484 0 2 0x5002 1 sh wait
303 70 70 1000 2 0x100 1 httpd netcon
350 70 70 1000 2 0x100 1 httpd netcon
415 70 70 1000 2 0x100 1 httpd netcon
397 70 70 1000 2 0x100 1 httpd netcon
392 70 70 1000 2 0x100 1 httpd netcon
369 70 70 1000 2 0x100 1 httpd netcon
297 70 70 1000 2 0x100 1 httpd netcon
284 70 70 1000 2 0x100 1 httpd netcon
302 307 70 1000 2 0x4000 1 perl netcon
307 70 70 1000 2 0x100 1 httpd select
70 1 70 0 2 0 1 httpd select
304 1 304 0 2 0x4003 1 ksh ttyin
310 1 310 0 2 0 1 cron nanosle
317 1 317 0 2 0 1 inetd kqread
298 1 298 8 2 0x100 1 exim-4.42-1 select
263 1 263 0 2 0 1 sshd select
148 1 148 14 2 0x100 1 named select
120 1 120 0 2 0 1 syslogd
5 0 0 0 2 0x20200 1 aiodoned aiodone
4 0 0 0 2 0x20200 1 ioflush syncer
3 0 0 0 2 0x20200 1 pagedaemon pgdaemo
2 0 0 0 2 0x20200 1 scsibus0 sccomp
1 0 1 0 2 0x4000 1 init wait
0 -1 0 0 2 0x20200 1 swapper
Unfortunately, I don't have the original panic message that would
have preceeded the "db>" prompt, because I wasn't logged in at the machine
acting as serial console for this machine at the time (and the machine
doesn't have screen(1) installed a.t.m).
Rebooting from the db> prompt works a lot better than during pthread
("ltsleep)" panics and I got some gcc/make output when I did it:
db> reboot
syncing disks... hme0: status=30003<GOTFRAME,RCNTEXP,RXTOHOST,NORXD>
e.
`inode.o' is up to date.
`main.
switching with held simple_lock 0x603c228 CPU 0
/usr/src/sys/uvm/uvm_anon.c:242
switching with held simple_lock 0x603c228 CPU 0
/usr/src/sys/uvm/uvm_anon.c:242
o' is up to date.
`pass1.o' is up to date.
`pass1b.o' is up to date.
`pass2.o' is up to date.
`pass3.o' i
switching with held simple_lock 0x603c228 CPU 0
/usr/src/sys/uvm/uvm_anon.c:242
s up to date.
`pass4.o' is up to date.
`pass5.o' is up to date.
`fsutil.o' is up to date.
`setup.o' is up to date.
`utilities.o
switching with held simple_lock 0x603c228 CPU 0
/usr/src/sys/uvm/uvm_anon.c:242
' is up to date.
`ext2fs_bswap.o' 2
switching with held simple_lock 0x603c228 CPU 0
/usr/src/sys/uvm/uvm_anon.c:242
is up1
switching with held simple_lock 0x603c228 CPU 0
/usr/src/sys/uvm/uvm_anon.c:242
to date.
done
unmounting /kern (kernfs)...
unmounting /local (/dev/sd1a)...
...followed by a lot more of
switching with held simple_lock 0x603c228 CPU 0 /usr/src/sys/uvm/uvm_anon.c:242
Anyone know what caused this fatal failure?
--
/ali
:wq