A fix for this has just been committed to -current by kette...@. Thanks again Mark.
On Wed, Dec 1, 2010 at 2:43 PM, Daniel Melameth <dan...@melameth.com> wrote: > 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.
