Hi,
while doing a bulk build on 2.0/alpha, I got 2 panics that could maybe explain
the file corrution in filesystem full condition some of us have reported.

The first one was:
uid 0, pid 21354, command tar, on /local/folk1: file system full
uid 0, pid 21354, command tar, on /local/folk1: file system full
panic: kernel diagnostic assertion "pg != NULL" failed: file "/big/builds/ab/netbsd-2-0-RELEASE/src/sys/arch/alpha/alpha/pmap.c", line 2655
(gdb) target kcore netbsd.0.core
panic: kernel %sassertion "%s" failed: file "%s", line %d
#0  0xfffffc0000769848 in dumpsys ()
(gdb) where
#0  0xfffffc0000769848 in dumpsys ()
#1  0xfffffc00007694b8 in cpu_reboot ()
#2  0xfffffc0000594024 in panic ()
#3  0xfffffc00007ee5f8 in __assert ()
#4  0xfffffc000076da68 in pmap_remove_mapping ()
#5  0xfffffc000076c148 in pmap_do_remove ()
#6  0xfffffc000063b89c in uvm_swapout ()
#7  0xfffffc000063b77c in uvm_swapout_threads ()
#8  0xfffffc000064d23c in uvmpd_scan ()
#9  0xfffffc000064c4d0 in uvm_pageout ()

The second one:
Jan 13 23:18:17 folk /netbsd: uid 0, pid 27261, command tar, on /local/folk1: file system full
Jan 13 23:18:17 folk last mpanic: pmap_destroy: pmap still contains valid mappings

Unfortunably, here the stack trace from gdb is less usefull:
(gdb) where
#0  0xfffffc0000769848 in dumpsys ()
#1  0xfffffc00007694b8 in cpu_reboot ()
#2  0xfffffc0000532c5c in db_reboot_cmd ()
#3  0xfffffc00005323c8 in db_command ()
#4  0xfffffc0000531f1c in db_command_loop ()
#5  0xfffffc0000536c8c in db_trap ()
#6  0xfffffc0000781ca8 in ddb_trap ()
#7  0xfffffc0000300194 in inc6 ()
#8  0xfffffc0000770e5c in trap ()
#9  0xfffffc00003003a4 in XentIF ()
#10 0xfffffc0000594058 in panic ()

any idea how to get past the panic() in the stack frame ?

this is with a 2.0 GENERIC kernel. I'm rebuilding GENERIC with -g
to try to have line numbers in source code.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--