Hmm.
Located the problem, although I'm not sure if this is the right fix. It 
will, however, make the system seem to work as it should.

I'm including a patch for this problem. It's actually only the last item 
that is the bugfix for this problem. I have a larger interrupt stack 
here locally. Not sure I really need it, but I've used that for a while 
for safety reasons...
Also, a (non)bug in the allocation of the scratch pages. A macro defines 
how many scratch pages to allocate, but in the code, a constant is used 
instead.

Maybe someone can check if the modification to pmap_page_protect_long() 
is sensible, and if so maybe commit this fix?

Now on to the next problem. It seems as if I can't build anything native 
on my VAX now... :-(

	Johnny

---snip---
diff -u -r1.148 pmap.c
--- pmap.c      12 Mar 2007 02:22:43 -0000      1.148
+++ pmap.c      12 Mar 2007 14:28:09 -0000
@@ -70,7 +70,7 @@
  #include "qd.h"
  void   qdearly(void);

-#define ISTACK_SIZE (PAGE_SIZE*2)
+#define ISTACK_SIZE (PAGE_SIZE*16)
  vaddr_t istack;
  /*
   * This code uses bitfield operators for most page table entries.
@@ -324,7 +324,7 @@
         scratch = istack + ISTACK_SIZE;

         /* Physical-to-virtual translation table */
-       pv_table = (struct pv_entry *)(scratch + 4 * VAX_NBPG);
+       pv_table = (struct pv_entry *)(scratch + SCRATCHPAGES * VAX_NBPG);

         avail_start = (vaddr_t)pv_table + (round_page(avail_end >> 
PGSHIFT)) *
             sizeof(struct pv_entry) - KERNBASE;
@@ -1606,7 +1606,8 @@
                             pt[2].pg_prot = pt[3].pg_prot =
                             pt[4].pg_prot = pt[5].pg_prot =
                             pt[6].pg_prot = pt[7].pg_prot =
-                           ((vaddr_t)pt < ptemapstart ? PROT_KR : PROT_RO);
+                           PROT_KR;
+                       /* ((vaddr_t)pt < ptemapstart ? PROT_KR : 
PROT_KR); */
                 } while ((pv = pv->pv_next));
         }
         PVTABLE_UNLOCK;
@@ -1851,4 +1852,3 @@
         kvtopte((vaddr_t)l->l_addr + REDZONEADDR)->pg_v = 0;
         pmap_activate(l);
  }

---snip---


Johnny Billquist wrote:
> Well, now that the kernel is semi-working again, I decided to update my 
> system, and start testing around.
> Installed the relevant sets, and started running etcupdate, but after a 
> while the kernel crash.
> 
> Anyone have an idea? I have the system at the ddb prompt now, so I can 
> muck around more if anyone have any ideas. Or I can recreate the 
> crash... :-)
> 
> This with a current kernel as of today. 4.99.14.
> 
>     Johnny
> 
> -----------------------
> Gnat:/home/bqt# etcupdate
> *** Creating /tmp/temproot
> *** Populating /tmp/temproot from /usr/src
> panic: Segv in kernel mode: pc 8017e898 addr 81fc0800
> Stopped in pid 2463.1 (cat) at  netbsd:trap+0x4fb:      movl    $1, -64(fp)
> db> bt
> panic: Segv in kernel mode: pc %x addr %x
> Stack traceback :
> 0x85204c64: trap+0x4fb(0x85204d2c)
> 0x85204d2c: trap type=0xc code=0x81fc0800 pc=0x8017e898 psl=0xc00000
> 0x85204cf8: pmap_page_protect_long+0x244(0x8030fce0,0x1)
> 0x85204d7c: uvm_loan+0x377(0x805ec628,0x3c000,0x4000,0x827dc760,0x2)
> 0x85204dec: 
> pipe_write+0x38c(0x8175283c,0x81752868,0x85204e9c,0x80d5e548,0x1)
> 0x85204e58: 
> dofilewrite+0x6f(0x81689ba0,0x1,0x8175283c,0x3c000,0x4000,0x81752868
> ,0x1,0x85204f74)
> 0x85204ed0: sys_write+0x4c(0x81689ba0,0x85204f54,0x85204f74)
> 0x85204f24: syscall_plain+0x8f(0x85204fb4)
> db>