AnsweredAssumed Answered

Ethernet Collisions Not handled

Question asked by Mike Underhill on May 24, 2013
Latest reply on Jan 31, 2014 by Mike Underhill
Branched to a new discussion

I have been testing i.MX6Q Ethernet functionality on a Nitrogen6x board and am seeing a problem at 10 Mbps half duplex running Linux release L3.0.35_4.0.0 (also tested with L3.0.35_12.09.01_GA).  I'm seeing occasional collisions when using a 10Mbps half duplex hub between a Linux-PC and the Nitrogen6x board, which is expected, however the Nitrogen6x board seems to lose the ping every time the hub's collision light blinks.  It should be automatically resending the packet after the collision, but the retransmission does not seem to be happening.  I've tried the same test between the Linux-PC and a Windows-PC and am seeing the same occasional collisions however there is no packet loss.  I can cause 100% packet loss by doing a simultaneous tftp transfer of a large file across the same hub, which greatly increases the likelihood of collisions.  Other devices tested are not affected by collisions generated by the tftp transfer.


To increase the likelihood of generating a collision I'm sending 100 large (30k) packets using the command:

ping -c 100 -s 30000

The result after 100 pings is:

--- ping statistics ---

100 packets transmitted, 96 packets received, 4% packet loss

round-trip min/avg/max = 50.463/75.662/1118.729 ms


I'm not sure if this is a hardware of software issue.  The Ethernet on this board is the i.MX6Q ENET (FEC) and a Micrel ksz9021rn PHY.



Has anyone else tested Ethernet on an i.MX6Q (Sabre Lite, Nitrogen6x, or similar) at 10 Mbps half duplex?    Any ideas where to look for the cause?