> > It looks like something has trashed the pv_table :-/
> > Please look at the first four longwords at address 0x80422df0
> > (or if you have rebooted, the argument to pmap_page_protect_long() if
> > it happens again).  That may give a hint what is broken.
> 
> K:
> 
> panic: Segv in kernel mode: pc 801acc04 addr 869a160f
> Stopped in pid 12276.1 (sort) at        netbsd:trap+0x619:      movl 
> $1, r11
> db> tr
> panic: Segv in kernel mode: pc %x addr %x
> Stack traceback :
> 0x89dfcc64: trap+0x619(0x89dfcd28)
> 0x89dfcd28: trap type=0xc code=0x869a160f pc=0x801acc04 psl=0xc00000
> 0x89dfccf4: pmap_page_protect_long+0x244(0x803fa4a0,0x1)
> 0x89dfcd78: uvm_loan+0x377(0x83f51e14,0x1ad000,0x3000,0x86fae4a0,0x2)
> 0x89dfcde8: 
> pipe_write+0x394(0x84bcc0f4,0x84bcc120,0x89dfce9c,0x86712898,0x1)
> 0x89dfce58: 
> dofilewrite+0x77(0x815bc914,0x1,0x84bcc0f4,0x1ad000,0x2430,0x84bcc12
> 0,0x1,0x89dfcf74)
> 0x89dfced0: sys_write+0x4b(0x815bc914,0x89dfcf54,0x89dfcf74)
> 0x89dfcf24: syscall_plain+0xa7(0x89dfcfb4)
> db> x/wx 0x803fa4a0,4
> 0x803fa4a0:     0           1af000      8705a040    84000000
> 
Ok, thanks.

It seems that there may be a few things that are erroneous:

- The P0 page table for the current process have been unmapped
- The pointer to the P0 page table in the pmap is overwritten
- The pv entry has not been removed as it should be (unlikely)

I assume that there is either a bug in gcc 4.0 or something in the
pmap code that are made visible with gcc 4.0.  Have you tried to
compiler a kernel without optimization?   Or at least compile
the pmap file without?  To see if it makes any difference.

-- Ragge