Hi,
Le 14/10/2016 à 15:40, Tom Rini a écrit :
On Fri, Oct 14, 2016 at 11:13:11AM +0200, Guillaume Gardet wrote:
Hi,
Le 14/10/2016 à 01:00, Joe Hershberger a écrit :
On Fri, Oct 14, 2016 at 12:52 AM, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On 13 October 2016 at 13:11, Tom Rini trini@konsulko.com wrote:
Hey all,
I've noticed now, but not dug into a problem that goes like this. On every platform that I have tried NFS on now (and I wasn't a user before the test came in) I see: # nfs 80000000 /tftpboot/1MiBtest.bin link up on port 0, speed 1000, full duplex ################################################################# ################################################################# ################################################################# ##########T T T T done Bytes transferred = 1048576 (100000 hex)
for the same 1MiB file. The link line will vary from board to board but the end result is that I always see 4 T (for timeout) at the end of the transfer. On boards where I am doing this on gigabit the initial transfer is fast enough that the timeout doesn't cause failure. On the boards where I'm at 100Mbit instead however, I fail.
I have seen this also - what type of interface are you using?
Does this happen in your testing, Guillaume?
No, I never saw those timeouts. I will try to reproduce here. On which boards does it happen?
AM335x GP EVM, DRA72x EVM ("J6 Eco"), Beagleboard xM, RPi 3 (32 or 64bit mode). I suspect it's something either config or network related. Everything is on the same 24 port gigabit switch.
I just tried 2016.11-rc2 on a Beagleboard xM with: * nfs download from a NFSv2 server * nfs download from a NFSv3 server * tftpboot download from a TFTP server
And all are working fine here.
Guillaume