From patchwork Thu Sep 12 10:22:02 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hector Palacios X-Patchwork-Id: 274493 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from theia.denx.de (theia.denx.de [85.214.87.163]) by ozlabs.org (Postfix) with ESMTP id 058202C0137 for ; Thu, 12 Sep 2013 20:29:56 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 17F6E4A023; Thu, 12 Sep 2013 12:29:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sssi3ItSR+nm; Thu, 12 Sep 2013 12:29:53 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id B55794A05E; Thu, 12 Sep 2013 12:29:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id D0E564A05E for ; Thu, 12 Sep 2013 12:29:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rBYmuUgqp6V for ; Thu, 12 Sep 2013 12:29:37 +0200 (CEST) X-Greylist: delayed 433 seconds by postgrey-1.27 at theia; Thu, 12 Sep 2013 12:29:31 CEST X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 (only DNSBL check requested) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.6]) by theia.denx.de (Postfix) with ESMTPS id 6FD384A023 for ; Thu, 12 Sep 2013 12:29:30 +0200 (CEST) Received: from [216.82.249.147:50061] by server-6.bemta-12.messagelabs.com id 81/D1-27960-6D591325; Thu, 12 Sep 2013 10:22:14 +0000 X-Env-Sender: Hector.Palacios@digi.com X-Msg-Ref: server-10.tower-29.messagelabs.com!1378981333!22247203!1 X-Originating-IP: [66.77.174.14] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18755 invoked from network); 12 Sep 2013 10:22:14 -0000 Received: from mail.mx4.digi.com (HELO mcl-sms-ns2.DIGI.COM) (66.77.174.14) by server-10.tower-29.messagelabs.com with RC4-SHA encrypted SMTP; 12 Sep 2013 10:22:14 -0000 Received: from MCL-VMS-XCH01.digi.com (10.5.8.49) by mail.mx2.digi.com (172.16.1.14) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 12 Sep 2013 05:22:15 -0500 Received: from dor-sms-exch01.digi.com (10.49.8.100) by MCL-VMS-XCH01.digi.com (10.5.8.49) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 12 Sep 2013 05:22:13 -0500 Received: from [10.101.1.181] (10.101.1.181) by dor-sms-exch01.digi.com (10.49.8.100) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 12 Sep 2013 12:22:11 +0200 Message-ID: <523195CA.3010305@digi.com> Date: Thu, 12 Sep 2013 12:22:02 +0200 From: Hector Palacios Organization: Digi International User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Marek Vasut References: <1373583784-7129-1-git-send-email-marex@denx.de> <201307160644.53198.marex@denx.de> <51E6BE61.1020908@digi.com> In-Reply-To: <51E6BE61.1020908@digi.com> Cc: Fabio Estevam , "u-boot@lists.denx.de" , Robert Hodaszi Subject: Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: u-boot-bounces@lists.denx.de Errors-To: u-boot-bounces@lists.denx.de Hello, Going back to this old thread I have some news regarding the problem with TFTP transmissions blocking (timed out) after 10 seconds on the FEC of the MX28. See below: On 07/17/2013 05:55 PM, Hector Palacios wrote: > Dear Marek, > > On 07/16/2013 06:44 AM, Marek Vasut wrote: >> Dear Fabio Estevam, >> >>> On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevam wrote: >>>> On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios >>>> >>>> wrote: >>>>> @Fabio: could you manually run the command 'tftp ${loadaddr} file100M' >>>>> in your EVK? >>>> >>>> Yes, this is what I have been running since the beginning. >>>> >>>>> If it doesn't fail, could you try running it again after playing with >>>>> the environment (setting/printing some variables). >>>> >>>> I can't reproduce the problem here. >>>> >>>>> As I said, this issue appeared with different TFTP servers and is >>>>> independent of whether the dcache is or not enabled. >>>> >>>> Can you transfer from a PC to another PC via TFTP? > > Yes I can. > >> Another thing of interest would be a 'tcpdump' pcap capture of that connection. > > I was initially filtering out only TFTP packets of my wireshark trace and all looked > correct. After taking a second look to the full trace I see now a hint. > Around 7 seconds after starting the TFTP transfer the server is sending an ARP to the > target asking for the owner of the target's IP. The target is receiving this ARP and > apparently responding (at least this is what my debug code shows as it gets into > arp.c:ArpReceive(), case ARPOP_REQUEST and sending a packet), but this ARP reply from > the target is not reaching the network. My sniffer does not capture this reply. > > The server resends the ARP request twice more (seconds 8 and 9) to the target and > since it doesn't get a reply then sends a broadcast ARP (seconds 10) asking who has > that IP. Since nobody responds it stops sending data. > > The times that it works (and I don't know the magic behind using a numeric address > versus using ${loadaddr} when they have the same value), the ARP replies do reach the > network and the server continues the transmission normally. > > Using a v2009 U-Boot, the behaviour is exactly the same, but the target's ARP replies > always reach the network, and the transfers always succeed. > > Since Fabio cannot reproduce it I guess it must be a local ghost. :o( We tracked down the issue to an ARP request from the server that was never answered by the target. We later noticed that the problem did not happen anymore when building U-Boot with a different toolchain and that the issue seemed to be in the alignment of the RX buffer in the stack, which old GCC compilers seem to do wrong. Here is a patch: From: Robert Hodaszi Date: Fri, 6 Sep 2013 09:50:52 +0200 Subject: [PATCH] net: fec: fix invalid temporary RX buffer alignment because of GCC bug Older GCC versions don't handle well alignment on stack variables. The temporary RX buffer is a local variable, so it is on the stack. Because the FEC driver is using DMA for transmission, receive and transmit buffers should be aligned on 64 byte. The transmit buffers are not allocated in the driver internally, it sends the packets directly as it gets them. So these packets should be aligned. When the ARP layer wants to reply to an ARP request, it uses the FEC driver's temporary RX buffer (used to pass data to the ARP layer) to store the new packet, and pass it back to the FEC driver's send function. Because of a GCC bug, this buffer is not aligned well, and when the driver tries to send it, it first rounds the address down to the alignment boundary. That causes invalid data. To fix it, don't put the temporary onto the stack. Signed-off-by: Robert Hodaszi Signed-off-by: Hector Palacios --- drivers/net/fec_mxc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index f4f72b7..315017e 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -828,7 +828,10 @@ static int fec_recv(struct eth_device *dev) uint16_t bd_status; uint32_t addr, size, end; int i; - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + /* Don't place this variable on the stack, because older GCC version + * doesn't handle alignement on stack well. + */ + static uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); /* * Check if any critical events have happened