From: sgalgano <sga...@ce...> - 2007-11-20 14:36:00
|
You need to add the iproute2 package. That will supply you with a full featured ping. I did see this problem before, as early as buildroot version 1533. My initial post: http://www.nabble.com/netwifi-microsd-ethernet-and-wifi-failure-under-load-tf4775005.html#a13659616 Steve Marc Humphreys wrote: > > With 1565 defconfig I get the following on my 2 net interfaces. > > # ping -f -s 1024 192.168.16.23 > BusyBox v1.1.2 (2007.11.19-01:23+0000) multi-call binary > > Usage: ping [OPTION]... host > > Send ICMP ECHO_REQUEST packets to network hosts. > > Options: > -c COUNT Send only COUNT pings > -s SIZE Send SIZE data bytes in packets (default=56) > -q Quiet mode, only displays output at start > and when finished > > # ping -f -s 1024 192.168.10.1 > BusyBox v1.1.2 (2007.11.19-01:23+0000) multi-call binary > > Usage: ping [OPTION]... host > > Send ICMP ECHO_REQUEST packets to network hosts. > > Options: > -c COUNT Send only COUNT pings > -s SIZE Send SIZE data bytes in packets (default=56) > -q Quiet mode, only displays output at start > and when finished > > Let me know what mods or additional pkgs I need to load to replicate your > setup. Obviously 1569 would help. Did you see this prior to 1569? > > Marc > > -----Original Message----- > From: gum...@li... > [mailto:gum...@li...] On Behalf Of Steven > Galgano > Sent: Monday, November 19, 2007 10:22 PM > To: gum...@li... > Subject: Re: [Gumstix-users] netwifi-microsd ethernet and wifi failure > underload > > Below are the details of my findings to date. One piece of very helpful > information would be knowing if anyone using a verdex with a > netwifi-microsd board has pushed a serious amount of traffic over the > ethernet and wifi simultaneously, such as in an ip forwarding function. > And if so, has the system been stable, i.e. the interfaces stayed up > throughout the traffic scenario. > > I have upgraded my testbed to buildroot 1569 and I am still experiencing > ethernet and wifi failures under load. > > I have eight verdex netwifi-microsd console board setups. They all > experience the same failure although some seem to be more susceptible > than others. > > One of the most repeatable methods that I have discovered to drop > ethernet connectivity is to connect a PC via ethernet and an ad-hoc > wireless connection to the gumstix: > > gumstix PC > -------- -- > eth0 10.1.1.4/8 eth0 10.1.1.10/8 > mwlan0 172.16.1.4/24 wlan0 172.16.1.10/24 > > Flood ping from the gumstix to the PC via ethernet using a serial > console login: > > gumstix> ping -f -s 1024 10.1.1.10 > > Then ping over the wifi link with a sufficiently large packet size > > pc> ping -c 2 -s 1500 172.16.1.4 > > You get a lot of these: > > ping: sent 1032 octets to 10.1.1.10, ret=-1 > .sendto: No buffer space available > > and then a lot of these: > > NETDEV WATCHDOG: eth0: transmit timed out > eth0: link down > eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 > > And no more eth0 connectivity even after you stop all the pings. > > The problem is not related to MTU or fragmentation. I was able to > make it occur with smaller packets over the wifi link but you just > require more at a faster rate to get the same ethernet failure. > > It may require more pings over the wifi. On some of my gumstixs I can > do it with 1 or 2 pings, on others it takes more. > > Sometimes the eth0 device fails every single time and others it seems to > work for hours. > > > Turning on debugging in the smc911x driver shows the following: > > -- output snibbit -- > > ... > > eth0: INT 0x0100002b MASK 0x008c42c8 OUTSIDE MASK 0x01000023 > eth0: RX irq > eth0: Rx FIFO pkts 1, bytes 104 > eth0: --> smc911x_rcv > eth0: Rx pkt len 102 status 0x00000020 > eth0: Received packet > 1c1d a676 7506 e1d0 001c 230d c09f 0800 > 4500 0054 0000 4000 4001 249a 0a01 010a > 0a01 0104 0800 2463 9d1a 0088 ed85 3c47 > 0000 0000 435a 0a00 0000 0000 1011 1213 > > eth0: INT 0x01000023 MASK 0x008c42c8 OUTSIDE MASK 0x01000023 > eth0: Interrupt done (4 loops) > eth0: Interrupt done (4 loops) > eth0: --> smc911x_hard_start_xmit > eth0: TX free space 7680 > eth0: --> smc911x_hardware_send_pkt > eth0: TX PKT LENGTH 0x0064 (100) BUF 0xc355f200 CMDA 0x00023062 CMDB > 0x00620062 > eth0: Transmitted packet > 0000 001c 230d c09f a676 7506 e1d0 0800 > 4500 0054 e86a 0000 4001 7c2f 0a01 0104 > 0a01 010a 0000 d7bf 9d1a 0004 eb85 3c47 > 0000 0000 9a81 0a00 0000 0000 1011 1213 > > eth0: --> smc911x_hard_start_xmit > eth0: TX free space 7680 > eth0: --> smc911x_hardware_send_pkt > eth0: TX PKT LENGTH 0x0064 (100) BUF 0xc361e600 CMDA 0x00023062 CMDB > 0x00620062 > eth0: Transmitted packet > 0000 001c 230d c09f a676 7506 e1d0 0800 > 4500 0054 e86b 0000 4001 7c2e 0a01 0104 > 0a01 010a 0000 7c97 9d1a 0005 eb85 3c47 > 0000 0000 f5a8 0a00 0000 0000 1011 1213 > > ... > > Please note that the 'RX irq' stops and with it eth0 connectivity. I > have noticed at the point of failure you see bit 24 of the IRQ status > register set. From my reading this is the RX Stopped (RXSTOP_INT) > signifying the receiver is halted. > > http://www.smsc.com/main/datasheets/9117.pdf page 75 > > To stop the receiver, the host must clear the MAC_CR:RXEN bit in the MAC > Control Register. When the receiver is halted, the INT_STS:RXSTOP_INT > bit will be set. Once stopped, the host can optionally clear the RX > Status and RX Data FIFOs. The host can re-enable the receiver by setting > the MAC_CR:RXEN bit. > > http://www.smsc.com/main/anpdf/an1212.pdf page 19 > > Why this occurs and whether or not it has anything to do with my problem > I am not sure. The driver does not uses that interrupt: > > From linux-2.6.21gum/drivers/net/smc911x.h: > > 323: #define INT_EN_RXSTOP_INT_EN_ (0x01000000) /* R/W */ > > From linux-2.6.21gum/drivers/net/smc911x.c: > > 371:/* now, enable interrupts */ > 372: mask = INT_EN_TDFA_EN_ | INT_EN_TSFL_EN_ | INT_EN_RSFL_EN_ | > 373: INT_EN_GPT_INT_EN_ | INT_EN_RXDFH_INT_EN_ | INT_EN_RXE_EN_ | > 375: INT_EN_PHY_INT_EN_; > > So my guess is that handling this condition is not required for normal > operation. So does anyone have an idea what might be going on here? > > > Thanks. > > -- > Steven Galgano > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/Re%3A-netwifi-microsd-ethernet-and-wifi-failure-under-load-tf4841047.html#a13857702 Sent from the Gumstix mailing list archive at Nabble.com. |