> I upgraded our ppp/mail server to 1.3.3 and the system paniced
> after 2 days of uptime (this system had uptimes of over 60 days
> before):
>
> # dmesg -M netbsd.1.core -N netbsd.1 | more
> ...
> vm_fault(0xf0846600, deadb000, 1, 0) -> 1
> fatal page fault in supervisor mode
> trap type 6 code 0 eip f0156f25 cs 8 eflags 10282 cr2 deadbf01 cpl 0
> panic: trap
> syncing disks... 7 7 done
>
> dumping to dev 1, offset 458876
> dump 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
> 6 5 4 3 2 1
>
> Does this tell anything to you gurus or should I do something more to
> trace the problem?

I don't think of myself as a guru, so you're probably well advised
to send any follow-up to this back to port-i386.  However, if I were
to look at this I would probably need a stack backtrace.  I think
(and hope) you can get it with gdb:

# gdb -q netbsd.1
(gdb) target kcore netbsd.1.core
(gdb) where

The second argument to vm_fault has a "funny" prefix, apparently
part of "0xdeadbeef", a common constant in NetBSD used for "this
pointer has now been invalidated", but apparently access was still
attempted through it.  Can you say "driver and/or kernel memory
management bug"?  (I knew you could. ;-)


- H=E5vard