I had a -3/80 crash on me today.

The source tree was supped 1997-05-21, and has a handful of my patches
applied.  I built a kernel, rebooted with it, did a "make build", and
left for Ottawa. :)  When I got back, it had panicked running out of VM
while doing the last step (the makewhatis); I rebooted, fscked, and
redid that one by hand, it was fine.  I did a little setup (fiddle
/etc/rc, /etc/rc.local, /etc/netstart - the originals came off the sun3
tarballs), and then tried to suck over a bunch of local software...and
it fell over hard:

Sol# /home/mouse/nc 132.206.73.75 7156 < /dev/null > src.tar &
[1] 149
Sol# ls -l
panic: pmap_zero_page: temporary vpages are in use.
Stopped at      _Debugger+0x6:  unlk    a6
db> trace
_Debugger(...) + 6
_panic(...) + 40
_pmap_zero_page(...) + 12
_vm_page_zero_fill(...) + 12
_vm_fault(...) + 3f4
_vm_fault_wire(...) + 36
_vm_map_pageable(...) + 25e
_kmem_malloc(f8555d00,2000,1) + c6
_m_clalloc(1,1) + 26
_am7990_get(f8567e00,2470,4f2) + 180
_am7990_read(f8567e00,2470,4f2) + 24
_am7990_rint(f8567e00) + a2
_am7990_intr(f8567e00) + c0
_isr_autovec(...) + 60
__isr_autovec(?)
_hardclock(...) + 4
_clock_intr(...) + 3c
__isr_clock(?)
_pmap_zero_page(...) + 4
_vm_page_zero_fill(...) + 12
_vm_fault(...) + 3f4
_trap(8,4030749,43ffc) + 3c8
faultstkadj() + 0

Well, yeah, if pmap_zero_page is entered recursively, I could well
believe "temporary vpages are in use".  I'm not quite sure what
provoked it, though, since it survived an entire "make build".  I did
do a "ps", and the fraction of the output that I judge worthwhile is

db> ps
  pid proc     addr     uid  ppid  pgrp  flag stat em  comm         wchan
  150 0xf8573600 0xf8fa2000   0   123   150  004006  2  netbsd  ls
  149 0xf8572800 0xf8f9e000   0   123   149  004006  2  netbsd  nc
...
(123 was the shell).

I then tried to continue, to get a crash dump, but it hung.  When I
typed a break to get back into ddb and did another trace,

db> trace
_Debugger(...) + 6
...usual zs break stuff...
_zshard(0) + 26
_isr_autovec(...) + 60
__isr_autovec(?)
_tsleep(...) + 4
_thread_sleep_msg(...) + 2c
_lock_write(...) + ba
_kmem_malloc(f8555d00,2000,1) + 46
_m_clalloc(1,1) + 26
_am7990_get(...) + 180
..._am7990_read, _am7990_rint, _am7990_intr, _isr_autovec...
__isr_autovec(?)
_vfs_shutdown(...) + 4
_reboot_sync(...) + 12
_cpu_reboot(...) + 1e
_panic(...) + 4a
...same as in the first call stack, after the first two lines.

I had to kick it hard; I never did get a crash dump.

Is this something re-supping is likely to cure, or is it Real Bug and I
should send-pr it?  Comparing the sys/arch/sun3{,x} subtrees between
the (pre-patched version of the) source tree from which the kernel was
built and that from this morning's sup does not show anything that
looks relevant, for what that may be worth.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B