From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3A71BB4C.9DF06097@adtran.com> Date: Fri, 26 Jan 2001 12:00:44 -0600 From: Ron Flory MIME-Version: 1.0 To: linuxppc-embedded@lists.linuxppc.org Subject: I'd like to pass on a fix for a nasty PPC860 FEC bug in 7-wire mode Content-Type: text/plain; charset=us-ascii Sender: owner-linuxppc-embedded@lists.linuxppc.org List-Id: hi- We are building a 860P/T based embedded system using the FEC that is present on this chip. Due to historical reasons, we are using the FEC in 7-wire mode (10 Mbit rate), not in MII mode. What we were seeing over the past few months was occasional RX packets with a reported length of over 52 Kbytes (!!) for pings and other data packets over 800 bytes long. We could repeatedly cause this to happen with ping-floods generated by a Linux/Unix/BSD machine: ping -nf -s1400 target_ip What we were able to determine was that the FEC was concatenating subsequent RX packets together (i.e. not correctly detecting inter- packet boundaries). The solution was to gate the RX_CLK signal from the PHY chip with the RX_DV signal, which blocks any RX clocks from reaching the FEC after the end of an RX packet. What we learned from a Moto FAE was that the FEC switches over to an internal clock when RX_DV is de-asserted, BUT it continues to see external clocks as well (which are random and async with respect to the internal clock). This problem is know to happen with several different PHY chips, even if they are configured in "Motorola" mode (the FEC is not well documented, so its hard to confirm timing compatibility from looking at the specs). I hope someone finds this of use- ron flory Adtran ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/