[U-Boot] [PATCH] net: Change the NFS_TIMEOUT to 20s for using nfs load image.
From: Jin Qing b24347@freescale.com
The NFS_TIMEOUT is 2s before. It is too short for some nfs server to respond.
Signed-off-by: Jin Qing b24347@freescale.com --- We are not sure what is the expected timeout period. Using 20s to make sure the mount works.
net/nfs.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/nfs.c b/net/nfs.c index 4017c3e..cabadfe 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -33,7 +33,7 @@
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 -#define NFS_TIMEOUT 2000UL +#define NFS_TIMEOUT 20000UL
static int fs_mounted = 0; static unsigned long rpc_id = 0;
Dear Li Yang,
In message 1281947653-5530-1-git-send-email-leoli@freescale.com you wrote:
From: Jin Qing b24347@freescale.com
The NFS_TIMEOUT is 2s before. It is too short for some nfs server to respond.
Signed-off-by: Jin Qing b24347@freescale.com
We are not sure what is the expected timeout period. Using 20s to make sure the mount works.
net/nfs.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/nfs.c b/net/nfs.c index 4017c3e..cabadfe 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -33,7 +33,7 @@
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 -#define NFS_TIMEOUT 2000UL +#define NFS_TIMEOUT 20000UL
You mean 30 retries (NFS_RETRY_COUNT) every two seconds were not sufficient in your case?
That's a full minute...
Waiting 10 minutes for a command to complete seems way too long to me.
Best regards,
Wolfgang Denk
On Mon, Aug 16, 2010 at 6:09 PM, Wolfgang Denk wd@denx.de wrote:
Dear Li Yang,
In message 1281947653-5530-1-git-send-email-leoli@freescale.com you wrote:
From: Jin Qing b24347@freescale.com
The NFS_TIMEOUT is 2s before. It is too short for some nfs server to respond.
Signed-off-by: Jin Qing b24347@freescale.com
We are not sure what is the expected timeout period. Using 20s to make sure the mount works.
net/nfs.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/nfs.c b/net/nfs.c index 4017c3e..cabadfe 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -33,7 +33,7 @@
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 -#define NFS_TIMEOUT 2000UL +#define NFS_TIMEOUT 20000UL
You mean 30 retries (NFS_RETRY_COUNT) every two seconds were not sufficient in your case?
That's a full minute...
It didn't retry 30 times before it fails completely in our test:
Load address: 0x400000 Loading: T T T T T *** ERROR: Cannot mount T T *** ERROR: Cannot umount
Looks like the state machine is not working as expected?
- Leo
Dear Li Yang,
In message AANLkTi=o6z1eBM1af94ZP5-s6_3Vf6TTP2VEdHDZWe=A@mail.gmail.com you wrote:
#define NFS_RETRY_COUNT 30 -#define NFS_TIMEOUT 2000UL +#define NFS_TIMEOUT 20000UL
You mean 30 retries (NFS_RETRY_COUNT) every two seconds were not sufficient in your case?
That's a full minute...
It didn't retry 30 times before it fails completely in our test:
Load address: 0x400000 Loading: T T T T T *** ERROR: Cannot mount T T *** ERROR: Cannot umount
Looks like the state machine is not working as expected?
...or something else is causing errors.
I have never seen such behaviour yet. Please try and debug it. Simply raising the timeout limit seems the wrong approach to me.
Best regards,
Wolfgang Denk
Dear Wolfgang,
The work flow is that: Every "timeout" is reached, it will call NfsSend() and whatever the state is finally it will call rpc_req() which will increase the rpc_id value every time. The rpc_id value is increased but the reply.id is not increased by "timeout". This makes the judgement statement: If (ntohl(rpc_pkt.u.reply.id) != rpc_id) is true and it will return -1. Then we got the error message: *** ERROR: Cannot mount.
So far, I am raising the timeout limit to avoid rpc_id being increased unexpectedly.
Do you have any suggestion about this issue?
Best Regards, Jin Qing
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: 2010年8月16日 18:46 To: Li Yang-R58472 Cc: u-boot@lists.denx.de; Jin Qing-B24347 Subject: Re: [U-Boot] [PATCH] net: Change the NFS_TIMEOUT to 20s for using nfs load image.
Dear Li Yang,
In message AANLkTi=o6z1eBM1af94ZP5-s6_3Vf6TTP2VEdHDZWe=A@mail.gmail.com you wrote:
#define NFS_RETRY_COUNT 30 -#define NFS_TIMEOUT 2000UL +#define NFS_TIMEOUT 20000UL
You mean 30 retries (NFS_RETRY_COUNT) every two seconds were not sufficient in your case?
That's a full minute...
It didn't retry 30 times before it fails completely in our test:
Load address: 0x400000 Loading: T T T T T *** ERROR: Cannot mount T T *** ERROR: Cannot umount
Looks like the state machine is not working as expected?
...or something else is causing errors.
I have never seen such behaviour yet. Please try and debug it. Simply raising the timeout limit seems the wrong approach to me.
Best regards,
Wolfgang Denk
Dear Jin Qing-B24347,
In message F37F9B48E0E59D42A5F9491A3CAD99AD7E8E37@zch01exm28.fsl.freescale.net you wrote:
The work flow is that: Every "timeout" is reached, it will call NfsSend() and whatever the state is finally it will call rpc_req() which will increase the rpc_id value every time. The rpc_id value is increased but the reply.id is not increased by "timeout". This makes the judgement statement: If (ntohl(rpc_pkt.u.reply.id) != rpc_id) is true and it will return -1. Then we got the error message: *** ERROR: Cannot mount.
So far, I am raising the timeout limit to avoid rpc_id being increased unexpectedly.
What sort of NFS server is this?
Best regards,
Wolfgang Denk
Dear Wolfgang
The work flow is that: Every "timeout" is reached, it will call NfsSend() and whatever the state is finally it will call rpc_req() which will increase the rpc_id value every time. The rpc_id value is increased but the reply.id is not increased by "timeout". This makes the judgement
statement:
If (ntohl(rpc_pkt.u.reply.id) != rpc_id) is true and it will return -1. Then we got the error message: *** ERROR: Cannot mount.
So far, I am raising the timeout limit to avoid rpc_id being
increased
unexpectedly.
What sort of NFS server is this?
It is a Debian NFS server.
Best regards, Jin Qing
participants (3)
-
Jin Qing-B24347 -
Li Yang -
Wolfgang Denk