9-STABLE -> NFS -> NetAPP:

[Marc Fournier]

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 <scrappy at 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 <rmacklem at uoguelph.ca> wrote:
> 
>> Marc Fournier wrote:
>>> On 2013-02-15, at 7:21 AM, Rick Macklem <rmacklem at 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 at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to
>>> "freebsd-stable-unsubscribe at freebsd.org"
>