Thank you for pointing that out to me. I'd seen it before but I didn't
make the connection that it was relevant. I'm now able to ping.
While trying to understand what was happening, I've also tried the
netCF-vx, which uses the smc91x driver. I was having difficulty with
that, but it was working (with lots of packet loss). I see it too is
using DMA; I wonder if these two drivers are sharing the same (broken?)
I've previously used DMA on both the Verdex and Connex, and there wasn't
any data integrity issues.
Thanks again, this has been very helpful.
[mailto:gumstix-users-bounces@...] On Behalf Of Mark
Sent: Wednesday, September 26, 2007 3:34 PM
Subject: Re: [Gumstix-users] Continued problems with netmicroSD
There is some kind of DMA hardware error on the netmicroSD boards, which
results in garbage data coming out of the ethernet port (even though
internally, networking seems to be fine). This would explain your
Eldridge discovered the fix when we were working on it this weekend. In
build_arm_nofpu/linux-2.6.21gum/drivers/net/smc911x.h, you need to
DMA. (#define SMC_USE_PXA_DMA 0)
#define SMC_USE_PXA_DMA 0=20
#define SMC_USE_16BIT 0=20
#define SMC_USE_32BIT 1=20
See his post for details:
Let me know once you've rebuilt the kernel whether this works for you.
worked for him and me.
Heilpern, Mark wrote:
> I'm currently using wireshark to try to understand what the cause of
> lack of networking may be, but so far the results are odd.
> My hardware is a 600MHz Verdex, with a netmicroSD (and console-vx)
> installed. My software is buildroot 1528, where the kernel config has
> been modified to include the driver for the netmicroSD as a module.
> (That is, both smc91x and smc911x are being built as modules.)
> The /etc/modules file is loading smc911x, and not smc91x. The
> /etc/modprobe.conf has "alias eth0 smc911x" (and the eth1 line is
> commented out).
> My eth0 entry in /etc/network/interfaces is:
> auto eth0
> iface eth0 inet static
> address 10.10.11.10
> netmask 255.255.254.0
> broadcast 10.10.11.255
> gateway 10.10.10.254
> At the tail of booting, just before the login prompt, I see:
> Starting network...
> eth0: link down
> Starting Rendezvous:
> NET: Registered protocol family 10
> ADDRCONF(NETDEV_UP): eth0: link is not ready
> Mobile IPv6
> Starting dropbear sshd: OK
> Starting httpd...
> Starting system message bus: eth0: link up, 100Mbps, half-duplex, lpa
> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> Immediately after logging in (after a reboot), "ifconfig" and "ip
> # ip route
> 10.10.10.0/23 dev eth0 src 10.10.11.10
> default via 10.10.10.254 dev eth0
> # ifconfig
> eth0 Link encap:Ethernet HWaddr 02:00:00:2F:C0:90
> inet addr:10.10.11.10 Bcast:10.10.11.255
> inet6 addr: fe80::ff:fe2f:c090/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:98 errors:0 dropped:0 overruns:0 frame:0
> TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:4892 (4.7 KiB) TX bytes:3401 (3.3 KiB)
> Interrupt:131 Base address:0x2000 DMA chan:9
> lo (not included, as irrelevant)
>>From the eth0 settings, it appears the network is working. After all
> there have been 13 packets sent and 98 received already. However,
> still is still no connectivity.
> At the moment I'm on a small isolated lan segment, with 4 machines
> (including the Verdex). All machines excluding the verdex are able to
> access each other without a hitch.
> One of those machines, "10.10.10.230", is running wireshark. One of
> others is able to "ping 10.10.10.230" without any issue, and wireshark
> shows full expected transactions.
>>From the verdex however, this is what I get:
> # ping 10.10.10.230
> PING 10.10.10.230 (10.10.10.230): 56 data bytes
> --- 10.10.10.230 ping statistics ---
> 4 packets transmitted, 0 packets received, 100% packet loss
> Now the odd part... wireshark showed 6 (essentially identical) packets
> as a result of that ping attempt. All show up as protocol "0x2a00"
> decodable to something by wireshark), from Ethernet address
> 00:2f:2a:00:08:06, to Ethernet address 2a:00:ff:ff:2a:00. I am sure
> these packats are a result of ping from the verdex, because additional
> attempts provide the same results (and since I've isolated my lan
> segment, there just isn't much other traffic).
> Looking at my verdex's Ethernet address (seen in ifconfig above)...
> neither of these!
> I'm at a loss to guess what the root cause here is. The only thing I
> think of (which doesn't seem likely to me) is that I've built my
> to support both Gumstix Ethernet types (but as modules, and I've
> confirmed that smc91x is not loaded). I would just swap out the
> but at the moment I'm not having good success with serial downloads
> lack of networking will make it difficult to recover if this fails.
> Any thoughts?
> NOTE: The information in this message is intended for the personal and
> confidential use
> of the designated recipient(s) named above. To the extent the
> is/are bound
> by a non-disclosure agreement, or other agreement that contains an
> obligation of
> confidentiality, with AuthenTec, then this message and/or any
> shall be
> considered confidential information and subject to the confidentiality
> terms of that
> agreement. If the reader of this message is not the intended
> named above, you
> are notified that you have received this document in error, and any
> review, dissemination,
> distribution or copying of this message is strictly prohibited. If you
> have received this
> document in error, please delete the original message and notify the
> sender immediately.
> Thank you.
> AuthenTec, Inc. http://www.authentec.com
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> gumstix-users mailing list
View this message in context:
Sent from the Gumstix mailing list archive at Nabble.com.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
gumstix-users mailing list