While looking into why one of my OpenBSD machines was locking up on
occasion, I have uncovered a series of repeatable steps that now reproduces
the issue on all OpenBSD machines I've tried it on--so I've decided to start
a new thread in the hopes of seeing it resolved.  Here are the steps:

# portmap
# mountd
# nfsd
# netstat -m
36 mbufs in use:
        30 mbufs allocated to data
        2 mbufs allocated to packet headers
        4 mbufs allocated to socket names and addresses
6/18/6144 mbuf 2048 byte clusters in use (current/peak/max)
4/12/6144 mbuf 4096 byte clusters in use (current/peak/max)
0/8/6144 mbuf 8192 byte clusters in use (current/peak/max)
0/8/6144 mbuf 9216 byte clusters in use (current/peak/max)
0/8/6144 mbuf 12288 byte clusters in use (current/peak/max)
0/8/6144 mbuf 16384 byte clusters in use (current/peak/max)
0/8/6144 mbuf 65536 byte clusters in use (current/peak/max)
268 Kbytes allocated to network (13% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
# pkill nfsd
# netstat -m

At this point the CPU is completely utilized, no panic is reported at the
console and the console is unresponsive.  Since this is reproducible on all
GENERIC machines I've tried it on, I assume a dmesg is unneeded.  I can
reproduce the problem on all 4.8-stable systems I've tried it on and a
recent snapshot.

Any thoughts appreciated.

[ message continues ]

sending a break over serial or ctrl-alt-esc on keyboard (if
ddb.console=1 is enabled) should enable you to get a trace even so.

[ message continues ]

The machine is unresponsive.  Ctrl-Alt-Esc with ddb.console=1 gets me
nowhere when this happens and, perhaps it's my machines or the machine
I'm using as a serial console, but sending a BREAK over serial doesn't
seem to get me into ddb either.

[ message continues ]

A fix for this has just been committed to -current by kettenis@.
Thanks again Mark.


[ message continues ]