>From: Brian D Chase <brianc@carpediem.com>
>
>It's probably worth noting that Bertram, the key contributer to the VS3100
>support, does development on a Model 76.  Some differences have shown up
>in the past between the M30/M38 and M76 so I imagine there are probably a
>few more lingering around.  No fault of Bertram's of course :-)

Well, if Bertram (or anyone else with a clue) wants one of my VS42-xx
systems to improve NetBSD's support for this system, all they need to
do is ask (I will even pay shipping).  I have a pile of three right
now that aren't being used for anything and aren't likely to be used
for anything any time soon.

Alternatively, if anyone has documentation on the low-level guts of
this hardware, I'd be willing to poke at it myself, to the limited
extent of my ability.  So far I've been able to trace the ps(1) panic
to its source but without more documentation I can't proceed very far.

In case anyone else cares, the problem seems to stem from the calls to
pmap_enter() and pmap_remove() in /sys/arch/vax/vax/mem.c:mmrw()
... my guess so far is that for some reason the second time the
pmap_enter() is called, the memory region isn't being mapped into
memory properly, so the eventual call to pmap_remove() fails.  The
code in ps that's triggering the bug is 
/usr/src/bin/ps/print.c:command() which calls
/usr/src/lib/libkvm/kvm_proc.c:kvm_getargv() which then calls some
other functions to actually map and read the kernel memory to get the
process's argv[] values.

The bug is not triggered if you avoid fetching any argv values,
e.g. "ps -c" run several times won't cause the panic.

That's all I know for now...

--
entropy -- it's not just a good idea, it's the second law.