On Wed, Dec 1, 2010 at 12:18 PM, Daniel Melameth <[email protected]> wrote: > On Mon, Nov 22, 2010 at 9:50 PM, Daniel Melameth <[email protected]> wrote: >> On Wed, Jul 7, 2010 at 8:45 PM, Daniel Melameth <[email protected]> wrote: >>> On Fri, Jun 18, 2010 at 11:08 PM, Daniel Melameth <[email protected]> wrote: >>>> On my firewall at home, on occasion, running systat queues leaves me with an >>>> unresponsive system. pings are not returned and the keyboard at the console >>>> is unresponsive. Sometimes the command works fine and sometimes it does >>>> not--though it does seem the issue is more likely to occur when the system >>>> has an uptime of more than a week or two. I'm uncertain how to troubleshoot >>>> this further and I have been unable to reproduce the issue on other >>>> 4.7-stable systems (though these other systems are not running the same >>>> hardware and software). >>> >>> I upgraded the system several days ago to a snapshot from just before >>> the hackathon, and the system appeared more stable, but I can now also >>> instantly kill the box by running netstat -m after about five days of >>> uptime. >>> >>> Ideas appreciated... >> >> FWIW, I thought I'd chime back with an update on this... I was able >> to reproduce the issue readily with 4.8-stable AND with different >> hardware, but I have been been unable to reproduce this since running >> a snapshot from November 7. The box currently has 14 days of uptime >> and numerous netstats and systats have not been able to hang it. > > Well, it would appear I spoke too soon. After 22 days of uptime, a > simple netstat -m again caused the box to lockup and I was left with > an unresponsive console and no apparent panic.
For the archives, this issue is now resolved. I was able to isolate the problem to nfsd and a fix has just been committed to -current--see http://www.openbsd.org/cgi-bin/cvsweb/src/sys/nfs/nfs_syscalls.c revision 1.92 for details (it appears this issue might have been introduced in revision 1.83.)
