Thank you for these patches.
One interesting thing: I was trying to backport them to 7.4.0 and
RELENG_7, too, but there the portion of the code dealing with the
RPC_CANTSEND case does not exist. On the other hand, the problem
surfaced (for me) when upgrading from 7.4 to 8.2. So could one
Martin Birgmeier wrote:
Thank you for these patches.
One interesting thing: I was trying to backport them to 7.4.0 and
RELENG_7, too, but there the portion of the code dealing with the
RPC_CANTSEND case does not exist. On the other hand, the problem
surfaced (for me) when upgrading from 7.4
Artem Belevich wrote:
On Thu, Aug 25, 2011 at 6:24 PM, Rick Macklem rmack...@uoguelph.ca
wrote:
Btw, I fixed exactly the same issue for the TCP code (clnt_vc.c) in
r221127, so I wouldn't be surprised if the UDP code suffers the same
The code in clnt_vc.c was exactly what made me wonder
On Fri, Aug 26, 2011 at 12:04 PM, Rick Macklem rmack...@uoguelph.ca wrote:
The patch looks good to me. The only thing is that *maybe* it should
also do the same for the other msleep() higher up in clnt_dg_call()?
(It seems to me that if this msleep() were to return ERESTART, the same
kernel
On Wed, Jul 6, 2011 at 4:50 AM, Martin Birgmeier la5lb...@aon.at wrote:
Hi Artem,
I have exactly the same problem as you are describing below, also with quite
a number of amd mounts.
In addition to the scenario you describe, another way this happens here
is when downloading a file via
Artem Belevich wrote:
On Wed, Jul 6, 2011 at 4:50 AM, Martin Birgmeier la5lb...@aon.at
wrote:
Hi Artem,
I have exactly the same problem as you are describing below, also
with quite
a number of amd mounts.
In addition to the scenario you describe, another way this happens
here
On Thu, Aug 25, 2011 at 6:24 PM, Rick Macklem rmack...@uoguelph.ca wrote:
Btw, I fixed exactly the same issue for the TCP code (clnt_vc.c) in
r221127, so I wouldn't be surprised if the UDP code suffers the same
The code in clnt_vc.c was exactly what made me wonder about treatment
of ERESTART.
Hi Artem,
I have exactly the same problem as you are describing below, also with quite
a number of amd mounts.
In addition to the scenario you describe, another way this happens here
is when downloading a file via firefox to a directory currently open in
dolphin (KDE file manager). This will
* We try to reconnect again, and again, and again
* the process in this state is unkillable
If you use the intr mount option, then an nfs reconnect
should be killable. I know diddly about amd, so I can't
help beyond that.
rick
___
On Thu, Jun 16, 2011 at 1:01 PM, Rick Macklem rmack...@uoguelph.ca wrote:
* We try to reconnect again, and again, and again
* the process in this state is unkillable
If you use the intr mount option, then an nfs reconnect
should be killable. I know diddly about amd, so I can't
help
Hi,
I wonder if someone else ran into this issue before and, maybe, have a solution.
I've been running into a problem where access to filesystems mouted
with amd wedges processes in an unkillable state and produces ICMP
storm on loopback interface.I've managed to narrow down to NFS
reconnect,
11 matches
Mail list logo
