From mboxrd@z Thu Jan 1 00:00:00 1970 From: PF4Public Date: Wed, 18 Feb 2015 18:33:48 +0300 Subject: [U-Boot] u-boot tftp problem In-Reply-To: References: <54DEAD72.3030801@mail.ru> Message-ID: <54E4B0DC.8080507@mail.ru> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de >Are you saying that it is completely consistent that when TFTPing from a specific TFTP server to u-boot you always get these time-outs, but with a different one you never get them? Exactly. Even when I try to download uImage from kvm host machine, I still got timeouts. But should I try to download from kvm guest, which obviously uses the same switch port as does host, I got fast download. A little slower, but still without timeouts, tftp gets uImage from MS Windows 7 host, which runs http://tftpd32.jounin.net/ .That was the first I could google up for Windows. >Have you compared the traffic on the wire? Careful examination of dumps leads me to the following conclusions: 1. Download session with timeouts had a lot of retransmissions. Having those dumps made on server side, I'm not certain if U-Boot really received lost packets, but what is clear is that tftpd sends some packets twice before receiving acknowledgement packet from U-Boot. 2. Even though Windows server uses block sizes 1500, still those packets are perfectly delivered to U-Boot. 3. Sometimes something really weird happens, like this: 00:00:00.000061 IP (tos 0x0, ttl 64, id 34608, offset 0, flags [DF], proto UDP (17), length 544) 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 423 00:00:00.000417 IP (tos 0x0, ttl 255, id 11691, offset 0, flags [DF], proto UDP (17), length 32) 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 423 00:00:00.000056 IP (tos 0x0, ttl 64, id 34609, offset 0, flags [DF], proto UDP (17), length 544) 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 424 00:00:05.000165 IP (tos 0x0, ttl 255, id 11692, offset 0, flags [DF], proto UDP (17), length 32) 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 423 00:00:00.000014 IP (tos 0x0, ttl 64, id 34720, offset 0, flags [DF], proto UDP (17), length 544) 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 424 00:00:00.000015 IP (tos 0x0, ttl 64, id 34721, offset 0, flags [DF], proto UDP (17), length 544) 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 424 00:00:00.000521 IP (tos 0x0, ttl 255, id 11693, offset 0, flags [DF], proto UDP (17), length 32) 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 424 That is tftpd sends block 423 and receives acknowledgement. Then it sends block 424, but the reply was delayed for 5 seconds and was in fact for block 423 again. This happened quite often with timing variations: 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 526 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 526 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 527 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 527 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 526 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 527 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 527 ... 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 1558 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 1558 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 1559 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 1559 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 1558 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 1559 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 1559 >Try turning on debug traces in the network stack and compare what it sees to what's on the wire. I'll give it a try, thanks. Is "#define DEBUG_NET_PKT 0" related here, which I found in include/net.h ? >Perhaps the davinci emac driver is causing you trouble. Is there a cache enabled on your board that you could disable to eliminate the driver's tolerance of a cache? You mean "CONFIG_SYS_ICACHE_OFF" and "CONFIG_SYS_DCACHE_OFF". I'll try them. I've googled something like "dcache off" command, but it didn't work for me in U-Boot command line, so suppose I should disable them via defines. Am I right? >Simply that the packet that the network stack expects has not be received at that level. They could be lost in a number of places. But how come they are lost so selectively? I mean that somehow packets from Windows and other Linux hosts got delivered just fine. Best regards.