| Message ID | 4FE85B13.5080902@kmckk.co.jp |
|---|---|
| State | Superseded |
| Delegated to: | Joe Hershberger |
| Headers | show |
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 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. 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 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. > 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.
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;
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(-)