--=-=-=


Martin Schmitz <martin-schmitz@web.de> wrote:

> I can't see any reason for a netbsd network server to reboot as long
> as there are no remote exploitable vulnerabilities in the kernel
> itself or a hardware failure occurs.

Oh, a kernel bug will do it too.  What's worse, in 1.6.1/i386
there is one that multiple sites have seen: kern/17564. :-(

uvm_fault(0xc06732a0, 0xffc00000, 0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 eip c0377403 cs 8 eflags 10206 cr2 ffc0097c cpl 0
panic: trap
Begin traceback...
trap() at trap+0x206
--- trap (number 6) ---
pmap_change_attrs(c095d254,0,40,11) at pmap_change_attrs+0x107
genfs_putpages(e33bfd40,e406789c,e33bfd2c,c02421bb,0) at genfs_putpages+0x449
ffs_putpages(e33bfd40,0,e33bfd58,ca23fa90,0) at ffs_putpages+0x11d
VOP_PUTPAGES(e416f88c,0,0,0,0,11,0,0) at VOP_PUTPAGES+0x49
ffs_full_fsync(e33bfe58,e416f88c,c10ee000,c02b2fa2,0) at ffs_full_fsync+0x98
ffs_fsync(e33bfe58,10012,e33bfe7c,c024d8f7,e416f88c) at ffs_fsync+0x3c
VOP_FSYNC(e416f88c,c0f44f00,0,0,0,0,0,e33c0004) at VOP_FSYNC+0x58
ffs_sync(c10ed000,3,c0f44f00,e33c0004) at ffs_sync+0xcf
sync_fsync(e33bff28,0,e33bff2c,c02b3f8f,ffffffff) at sync_fsync+0x5c
VOP_FSYNC(e33e1c8c,c0f44f00,8,0,0,0,0,e33c0004) at VOP_FSYNC+0x58
sched_sync(e33c0004) at sched_sync+0xb1
End traceback...

This bug is particularly awkward: it's rare -- sometimes minutes,
sometimes months between occurances and there is no crash dump
written and the kernel doesn't reboot.  Hard to troubleshoot.

Giles


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iQCVAwUBQD3X7WFrjZTaaO5BAQFRCAP/WRozVuIOIwLujwk3aWNyc8i87TyoW2YJ
D5xVQm66fSQtgTmZWtsHqeIxzFWH8iYG9i5KX4YZezfzvhmWvWVtOP33WtJ6BOnq
matj2OhoZArSJMBCe3c00w6Z2k3+gFaLHxfg0n191/Jy8ZG6wnxJHJHM/L5J0rGv
hI3QVO2RhP8=
=1Vgv
-----END PGP SIGNATURE-----
--=-=-=--