Menu
▾
▴
Re: [Gumstix-users] netwifi-microsd ethernet and wifi failure underload
|
From: Marc H. <mhu...@lo...> - 2007-11-20 06:10:48
|
Steven, What power are you providing to your hardware stack? Voltage and Current specs on your supply? What else do you have plugged in to your boards. USB hub/devices/keyboard etc? 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 |