Re: 9-STABLE -> NFS -> NetAPP:

According to /var/log/messages, everything seems to have been running (at l=
east against the local file system) up until the reboot:

=3D=3D=3D
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.
=3D=3D=3D

On 2013-02-18, at 4:12 AM, Marc Fournier <scrappy@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 log=
in prompt, but after typing login id, it appears to just hang =85
> =

> Remotely power cycled server.
> =

> This is new behaviour for that server since applying patch =85 will see i=
f it happens again ...
> =

> =

> On 2013-02-17, at 7:07 AM, Rick Macklem <rmacklem@uoguelph.ca> wrote:
> =

>> Marc Fournier wrote:
>>> On 2013-02-15, at 7:21 AM, Rick Macklem <rmacklem@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 =85
>>> =

>> 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-unsubscribe@freebsd.org"
> =

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"