[U-Boot] [RFC][PATCH] net: nfs: extend NFS_TIMEOUT
I tried nfs command on KZM-A9-GT board and it fails every time with "ERROR: Cannot umount". Current NFS_TIMEOUT value is 2000UL. It seems too short. I changed this to 10000UL then it succeeds.
Signed-off-by: Tetsuyuki Kobayashi koba@kmckk.co.jp --- net/nfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/nfs.c b/net/nfs.c index 5b99763..390c6ee 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -31,7 +31,7 @@
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 -#define NFS_TIMEOUT 2000UL +#define NFS_TIMEOUT 10000UL
static int fs_mounted; static unsigned long rpc_id;
Dear Tetsuyuki Kobayashi,
In message 4FE85B13.5080902@kmckk.co.jp you wrote:
I tried nfs command on KZM-A9-GT board and it fails every time with "ERROR: Cannot umount".
KZM-A9-GT board? This is an out of tree port, isn't it?
Are you sure the problems are not in the board specific code?
Current NFS_TIMEOUT value is 2000UL. It seems too short. I changed this to 10000UL then it succeeds.
Please don't modify global code when you just need different settings for a single piece of hardware. Especially here, were there are chances that the problems are actually in the board support code, and not in the global network code.
Best regards,
Wolfgang Denk
Hello, Wolfgang Denk, Thank you for responding.
(06/26/2012 06:34 AM), Wolfgang Denk wrote:
In message 4FE85B13.5080902@kmckk.co.jp you wrote:
I tried nfs command on KZM-A9-GT board and it fails every time with "ERROR: Cannot umount".
KZM-A9-GT board? This is an out of tree port, isn't it?
Not yet, but trying now.
Are you sure the problems are not in the board specific code?
OK. I will try the same thing on an in-tree board (maybe, panda board) to check if this is board specific or not.
Current NFS_TIMEOUT value is 2000UL. It seems too short. I changed this to 10000UL then it succeeds.
Please don't modify global code when you just need different settings for a single piece of hardware. Especially here, were there are chances that the problems are actually in the board support code, and not in the global network code.
Yes. I understand.
Hello,
(2012/06/26 9:50), Tetsuyuki Kobayashi wrote:
(06/26/2012 06:34 AM), Wolfgang Denk wrote:
In message4FE85B13.5080902@kmckk.co.jp you wrote:
I tried nfs command on KZM-A9-GT board and it fails every time with "ERROR: Cannot umount".
KZM-A9-GT board? This is an out of tree port, isn't it?
Not yet, but trying now.
Are you sure the problems are not in the board specific code?
OK. I will try the same thing on an in-tree board (maybe, panda board) to check if this is board specific or not.
I did on a panda board. It has the same problem and this patch solves it. So this is not board specific problem. Please consider to change global setting of NFS_TIMEOUT in nfs.c. I hope someone else tries nfs command on the other board.
Following is the detail I did:
The default config of pand board disables NFS command. So add this line in omap4_panda.h #define COFNIG_CMD_NFS (This line must be after #include configs/omap4_common.h>
I had trouble to use network on a panda board at the source from u-boot master git. Instead, I used source code from Linaro git. (I think this is another issue. Just focus NFS timeout now.)
Before applying the patch: error occurs like this.
Panda # usb start (Re)start USB... USB: Register 1313 NbrPorts 3 USB EHCI 1.00 scanning bus for devices... 3 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 1 Ethernet Device(s) found Panda # setenv ipaddr 192.168.1.162 Panda # setenv serverip 192.168.1.110 Panda # nfs /export/tmp/uImage Waiting for Ethernet connection... done. Using sms0 device File transfer via NFS from server 192.168.1.110; our IP address is 192.168.1.162 Filename '/export/tmp/uImage'. Load address: 0x82000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ##############################################T T *** ERROR: Cannot umount Panda #
After applying the patch: it seems OK.
Panda # usb start (Re)start USB... USB: Register 1313 NbrPorts 3 USB EHCI 1.00 scanning bus for devices... 3 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 1 Ethernet Device(s) found Panda # setenv ipaddr 192.168.1.162 Panda # setenv serverip 192.168.1.110 Panda # nfs /export/tmp/uImage Waiting for Ethernet connection... done. Using sms0 device File transfer via NFS from server 192.168.1.110; our IP address is 192.168.1.162 Filename '/export/tmp/uImage'. Load address: 0x82000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############################################## done Bytes transferred = 2230644 (220974 hex) Panda #
-- Tetsuyuki Kobayashi
Dear Tetsuyuki Kobayashi,
In message 4FE9711A.2090602@kmckk.co.jp you wrote:
Are you sure the problems are not in the board specific code?
OK. I will try the same thing on an in-tree board (maybe, panda board) to check if this is board specific or not.
I did on a panda board. It has the same problem and this patch solves it. So this is not board specific problem. Please consider to change global setting of NFS_TIMEOUT in nfs.c.
net/nfs.c is not the right place to make board specific adjustments.
I am still not convinced this is an issue with the global code. It could be your NFS server as well.
If there are really boards which need longer timeouts, these should be set in the board config files.
Best regards,
Wolfgang Denk
Hi Tetsuyuki,
On Tue, Jun 26, 2012 at 3:52 AM, Wolfgang Denk wd@denx.de wrote:
Dear Tetsuyuki Kobayashi,
In message 4FE9711A.2090602@kmckk.co.jp you wrote:
Are you sure the problems are not in the board specific code?
OK. I will try the same thing on an in-tree board (maybe, panda board) to check if this is board specific or not.
I did on a panda board. It has the same problem and this patch solves it. So this is not board specific problem. Please consider to change global setting of NFS_TIMEOUT in nfs.c.
net/nfs.c is not the right place to make board specific adjustments.
I am still not convinced this is an issue with the global code. It could be your NFS server as well.
I'm not convinced either. It clearly depends on the speed of your server, the speed of the connection, the size of the file you are transferring, etc.
If there are really boards which need longer timeouts, these should be set in the board config files.
In fact I would rather the constant were not defined there at all... but it is.
At a minimum it should look like this:
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 +#ifdef CONFIG_NFS_TIMEOUT +#define NFS_TIMEOUT CONFIG_NFS_TIMEOUT +#else #define NFS_TIMEOUT 2000UL +#endif
static int fs_mounted; static unsigned long rpc_id;
...with CONFIG_NFS_TIMEOUT defined for your board.
-Joe
On 06/26/2012 10:30 AM, Joe Hershberger wrote:
Hi Tetsuyuki,
On Tue, Jun 26, 2012 at 3:52 AM, Wolfgang Denk wd@denx.de wrote:
Dear Tetsuyuki Kobayashi,
In message 4FE9711A.2090602@kmckk.co.jp you wrote:
Are you sure the problems are not in the board specific code?
OK. I will try the same thing on an in-tree board (maybe, panda board) to check if this is board specific or not.
I did on a panda board. It has the same problem and this patch solves it. So this is not board specific problem. Please consider to change global setting of NFS_TIMEOUT in nfs.c.
net/nfs.c is not the right place to make board specific adjustments.
I am still not convinced this is an issue with the global code. It could be your NFS server as well.
I'm not convinced either. It clearly depends on the speed of your server, the speed of the connection, the size of the file you are transferring, etc.
Is the timeout for completing the transfer, or for making forward progress?
-Scott
Hi Scott,
On Tue, Jun 26, 2012 at 1:34 PM, Scott Wood scottwood@freescale.com wrote:
On 06/26/2012 10:30 AM, Joe Hershberger wrote:
Hi Tetsuyuki,
On Tue, Jun 26, 2012 at 3:52 AM, Wolfgang Denk wd@denx.de wrote:
Dear Tetsuyuki Kobayashi,
In message 4FE9711A.2090602@kmckk.co.jp you wrote:
Are you sure the problems are not in the board specific code?
OK. I will try the same thing on an in-tree board (maybe, panda board) to check if this is board specific or not.
I did on a panda board. It has the same problem and this patch solves it. So this is not board specific problem. Please consider to change global setting of NFS_TIMEOUT in nfs.c.
net/nfs.c is not the right place to make board specific adjustments.
I am still not convinced this is an issue with the global code. It could be your NFS server as well.
I'm not convinced either. It clearly depends on the speed of your server, the speed of the connection, the size of the file you are transferring, etc.
Is the timeout for completing the transfer, or for making forward progress?
The timeout is reset each time that NetSetTimeout() is called. For NFS, that happens when a transfer starts, when the timeout occurs (a retry begins), and when a "read request" response comes from the server. I would bet that means it should be a timeout for making progress, but I'm not an NFS protocol expert.
-Joe
Hi Joe, Thank you for responding.
(2012/06/27 0:30), Joe Hershberger wrote:
On Tue, Jun 26, 2012 at 3:52 AM, Wolfgang Denkwd@denx.de wrote:
Dear Tetsuyuki Kobayashi,
In message4FE9711A.2090602@kmckk.co.jp you wrote:
Are you sure the problems are not in the board specific code?
OK. I will try the same thing on an in-tree board (maybe, panda board) to check if this is board specific or not.
I did on a panda board. It has the same problem and this patch solves it. So this is not board specific problem. Please consider to change global setting of NFS_TIMEOUT in nfs.c.
net/nfs.c is not the right place to make board specific adjustments.
I am still not convinced this is an issue with the global code. It could be your NFS server as well.
I'm not convinced either. It clearly depends on the speed of your server, the speed of the connection, the size of the file you are transferring, etc.
Yes, NFS_TIMEOUT should be configurable.
If there are really boards which need longer timeouts, these should be set in the board config files.
In fact I would rather the constant were not defined there at all... but it is.
At a minimum it should look like this:
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 +#ifdef CONFIG_NFS_TIMEOUT +#define NFS_TIMEOUT CONFIG_NFS_TIMEOUT +#else #define NFS_TIMEOUT 2000UL +#endif
static int fs_mounted; static unsigned long rpc_id;
...with CONFIG_NFS_TIMEOUT defined for your board.
Thanks. I agree this change.
NFS_TIMEOUT is constant value defined in net/nfs.c. But sometimes it needs to adjust. This patch enables to override NFS_TIMEOUT by defining CONFIG_NFS_TIMEOUT in a board specific config file.
Signed-off-by: Tetsuyuki Kobayashi koba@kmckk.co.jp --- Hello,
I made a patch from Joe's idea.
net/nfs.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/net/nfs.c b/net/nfs.c index 5b99763..6e65c5a 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -31,7 +31,12 @@
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 +#ifdef CONFIG_NFS_TIMEOUT +#define NFS_TIMEOUT CONFIG_NFS_TIMEOUT +#error "" +#else #define NFS_TIMEOUT 2000UL +#endif
static int fs_mounted; static unsigned long rpc_id;
On Jul 3, 2012, at 6:22 AM, Tetsuyuki Kobayashi koba@kmckk.co.jp wrote:
NFS_TIMEOUT is constant value defined in net/nfs.c. But sometimes it needs to adjust. This patch enables to override NFS_TIMEOUT by defining CONFIG_NFS_TIMEOUT in a board specific config file.
Signed-off-by: Tetsuyuki Kobayashi koba@kmckk.co.jp
Hello,
I made a patch from Joe's idea.
net/nfs.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/net/nfs.c b/net/nfs.c index 5b99763..6e65c5a 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -31,7 +31,12 @@
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 +#ifdef CONFIG_NFS_TIMEOUT +#define NFS_TIMEOUT CONFIG_NFS_TIMEOUT +#error ""
Why error?
+#else #define NFS_TIMEOUT 2000UL +#endif
static int fs_mounted; static unsigned long rpc_id; -- 1.7.9.5
Hello Joe, thanks to responding.
On 2012/07/03, at 22:47, Joe Hershberger wrote:
On Jul 3, 2012, at 6:22 AM, Tetsuyuki Kobayashi koba@kmckk.co.jp wrote:
NFS_TIMEOUT is constant value defined in net/nfs.c. But sometimes it needs to adjust. This patch enables to override NFS_TIMEOUT by defining CONFIG_NFS_TIMEOUT in a board specific config file.
Signed-off-by: Tetsuyuki Kobayashi koba@kmckk.co.jp
Hello,
I made a patch from Joe's idea.
net/nfs.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/net/nfs.c b/net/nfs.c index 5b99763..6e65c5a 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -31,7 +31,12 @@
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 +#ifdef CONFIG_NFS_TIMEOUT +#define NFS_TIMEOUT CONFIG_NFS_TIMEOUT +#error ""
Why error?
Oh, I'm sorry. It is mistake. I checked both case inserting #error and forgot to remove.. I will post V2.
+#else #define NFS_TIMEOUT 2000UL +#endif
static int fs_mounted; static unsigned long rpc_id; -- 1.7.9.5
NFS_TIMEOUT is constant value defined in net/nfs.c. But sometimes it needs to adjust. This patch enables to override NFS_TIMEOUT by defining CONFIG_NFS_TIMEOUT in a board specific config file. For example, #define CONFIG_NFS_TIMEOUT 10000UL
Signed-off-by: Tetsuyuki Kobayashi koba@kmckk.co.jp --- Changes for v2: - remove a wrong #error line
net/nfs.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/net/nfs.c b/net/nfs.c index 5b99763..3a7f123 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -31,7 +31,11 @@
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 +#ifdef CONFIG_NFS_TIMEOUT +#define NFS_TIMEOUT CONFIG_NFS_TIMEOUT +#else #define NFS_TIMEOUT 2000UL +#endif
static int fs_mounted; static unsigned long rpc_id;
Dear Tetsuyuki Kobayashi,
In message 4FF3AEC4.9050808@kmckk.co.jp you wrote:
NFS_TIMEOUT is constant value defined in net/nfs.c. But sometimes it needs to adjust. This patch enables to override NFS_TIMEOUT by defining CONFIG_NFS_TIMEOUT in a board specific config file. For example, #define CONFIG_NFS_TIMEOUT 10000UL
Please add documentation to the new CONFIG_ option to the README.
Thanks.
Best regards,
Wolfgang Denk
NFS_TIMEOUT is constant value defined in net/nfs.c. But sometimes it needs to adjust. This patch enables to override NFS_TIMEOUT by defining CONFIG_NFS_TIMEOUT in a board specific config file.
Signed-off-by: Tetsuyuki Kobayashi koba@kmckk.co.jp --- Changes for v2: - remove a wrong #error line Changes for v3: - add CONFIG_NFS_TIMEOUT after CONFIG_ARP_TIMEOUT in README file - align #ifndef - #else - #endif format as same as tftp.c
README | 7 +++++++ net/nfs.c | 6 +++++- 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/README b/README index 67dc444..9a18a5c 100644 --- a/README +++ b/README @@ -2140,6 +2140,13 @@ The following options need to be configured:
Timeout waiting for an ARP reply in milliseconds.
+ CONFIG_NFS_TIMEOUT + + Timeout in milliseconds used in NFS protocol. + If you encounter "ERROR: Cannot umount" in nfs command, + try longer timeout such as + #define CONFIG_NFS_TIMEOUT 10000UL + - Command Interpreter: CONFIG_AUTO_COMPLETE
diff --git a/net/nfs.c b/net/nfs.c index 5b99763..7f2393f 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -31,7 +31,11 @@
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 -#define NFS_TIMEOUT 2000UL +#ifndef CONFIG_NFS_TIMEOUT +# define NFS_TIMEOUT 2000UL +#else +# define NFS_TIMEOUT CONFIG_NFS_TIMEOUT +#endif
static int fs_mounted; static unsigned long rpc_id;
Dear Joe Hershberger,
How is this patch's status?
(2012/07/04 17:25), Tetsuyuki Kobayashi wrote:
NFS_TIMEOUT is constant value defined in net/nfs.c. But sometimes it needs to adjust. This patch enables to override NFS_TIMEOUT by defining CONFIG_NFS_TIMEOUT in a board specific config file.
Signed-off-by: Tetsuyuki Kobayashi koba@kmckk.co.jp
Changes for v2: - remove a wrong #error line Changes for v3: - add CONFIG_NFS_TIMEOUT after CONFIG_ARP_TIMEOUT in README file - align #ifndef - #else - #endif format as same as tftp.c
README | 7 +++++++ net/nfs.c | 6 +++++- 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/README b/README index 67dc444..9a18a5c 100644 --- a/README +++ b/README @@ -2140,6 +2140,13 @@ The following options need to be configured:
Timeout waiting for an ARP reply in milliseconds.
CONFIG_NFS_TIMEOUTTimeout in milliseconds used in NFS protocol.If you encounter "ERROR: Cannot umount" in nfs command,try longer timeout such as#define CONFIG_NFS_TIMEOUT 10000UL
- Command Interpreter: CONFIG_AUTO_COMPLETE
diff --git a/net/nfs.c b/net/nfs.c index 5b99763..7f2393f 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -31,7 +31,11 @@
#define HASHES_PER_LINE 65 /* Number of "loading" hashes per line */ #define NFS_RETRY_COUNT 30 -#define NFS_TIMEOUT 2000UL +#ifndef CONFIG_NFS_TIMEOUT +# define NFS_TIMEOUT 2000UL +#else +# define NFS_TIMEOUT CONFIG_NFS_TIMEOUT +#endif
static int fs_mounted; static unsigned long rpc_id;
Hi Tetsuyuki Kobayashi,
On Thu, Jul 12, 2012 at 2:30 AM, Tetsuyuki Kobayashi koba@kmckk.co.jp wrote:
Dear Joe Hershberger,
How is this patch's status?
Someone marked it as RFC in patchwork, so I lost track of it.
I'll apply it to next.
Thanks, -Joe
On Thu, Jul 12, 2012 at 11:16:00AM -0500, Joe Hershberger wrote:
Hi Tetsuyuki Kobayashi,
On Thu, Jul 12, 2012 at 2:30 AM, Tetsuyuki Kobayashi koba@kmckk.co.jp wrote:
Dear Joe Hershberger,
How is this patch's status?
Someone marked it as RFC in patchwork, so I lost track of it.
That would be me (went and took everything with RFC in the subject, marked it as RFC). Sorry for the inconvienece!
Hi Tom,
On Thu, Jul 12, 2012 at 11:30 AM, Tom Rini trini@ti.com wrote:
On Thu, Jul 12, 2012 at 11:16:00AM -0500, Joe Hershberger wrote:
Hi Tetsuyuki Kobayashi,
On Thu, Jul 12, 2012 at 2:30 AM, Tetsuyuki Kobayashi koba@kmckk.co.jp wrote:
Dear Joe Hershberger,
How is this patch's status?
Someone marked it as RFC in patchwork, so I lost track of it.
That would be me (went and took everything with RFC in the subject, marked it as RFC). Sorry for the inconvienece!
No problem... the RFC should have been removed from the subject line if Tetsuyuki Kobayashi expected it to be applied.
Thanks, -Joe
Hi Joe, Tom,
(2012/07/13 1:40), Joe Hershberger wrote:
Hi Tom,
On Thu, Jul 12, 2012 at 11:30 AM, Tom Rini trini@ti.com wrote:
On Thu, Jul 12, 2012 at 11:16:00AM -0500, Joe Hershberger wrote:
Hi Tetsuyuki Kobayashi,
On Thu, Jul 12, 2012 at 2:30 AM, Tetsuyuki Kobayashi koba@kmckk.co.jp wrote:
Dear Joe Hershberger,
How is this patch's status?
Someone marked it as RFC in patchwork, so I lost track of it.
That would be me (went and took everything with RFC in the subject, marked it as RFC). Sorry for the inconvienece!
No problem... the RFC should have been removed from the subject line if Tetsuyuki Kobayashi expected it to be applied.
OK. I will do so in next time. Thank you.
participants (5)
-
Joe Hershberger -
Scott Wood -
Tetsuyuki Kobayashi -
Tom Rini -
Wolfgang Denk