According to /var/log/messages, everything seems to have been running (at least against the local file system) up until the reboot:
=== Feb 18 12:00:00 mercury kernel: bce1: promiscuous mode disabled Feb 18 12:00:00 mercury kernel: bce1: promiscuous mode enabled Feb 18 12:13:55 mercury syslogd: kernel boot file is /boot/kernel/kernel Feb 18 12:13:55 mercury kernel: Copyright (c) 1992-2013 The FreeBSD Project. === On 2013-02-18, at 4:12 AM, Marc Fournier <scra...@hub.org> wrote: > > 2days, 6hrs since reboot with new kernel, server shows unreachable: > > # ssh mercury > ssh_exchange_identification: Connection closed by remote host > > although runtime shows it is up: > > mercury up 2+06:17, 0 users, load 0.63, 0.69, 0.70 > > Remote console shows: > > <Screen Shot 2013-02-18 at 4.06.02 AM.png> > > I could press return, so keyboard was still responsive, and got a new login > prompt, but after typing login id, it appears to just hang … > > Remotely power cycled server. > > This is new behaviour for that server since applying patch … will see if it > happens again ... > > > On 2013-02-17, at 7:07 AM, Rick Macklem <rmack...@uoguelph.ca> wrote: > >> Marc Fournier wrote: >>> On 2013-02-15, at 7:21 AM, Rick Macklem <rmack...@uoguelph.ca> wrote: >>> >>>>> >>>> Righto. Thanks jhb and kib for looking at this. >>>> >>>> Btw John, PBDRY still gets set for sleeps in the sys/rpc code. >>>> However, >>>> as far as I can tell, it just sets TDF_SBDRY when it is already set >>>> and seems harmless. (Since this code is supposed to be generic and >>>> not >>>> specific to NFS, maybe it should stay that way?) >>>> >>>> Also, since PBDRY on the sleeps sets TDF_SBDRY, I think the above >>>> patch >>>> is ok for stable/9 without your recent head patch. >>>> >>>> Maybe Marc can test the above patch? >>> >>> 'k, not sure what you want me to 'test', but so far, patch has been >>> applied / live for ~21hrs, and no processes in state T … >>> >> Yes, I meant run it like you normally do and see if the hang occurs >> with the patch (or other problems crop up). I suspect you have some >> idea of how long it needs to run without a hang before you are convinced >> the problem is fixed. >> >> I can't do commits until April, so there is no rush from my point of >> view. (I suspect jhb@ will commit it at some point, if/when it appears >> to fix the problem and seems correct.) >> >> Thanks for testing it, rick >> >>> >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscr...@freebsd.org" > _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"