Hi,
I use a 2.4.18 Linux kernel on my custom 8260 board with 3 FCC ports.
These 3 ports work fine at 100Mbs half or full duplex.
I connect 2 boards on the first port via a 10Mbs hub.
The ports auto-negotiate and fall into 10Mbs half duplex mode.
A board sends short udp messages as fast as possible to the other one
and vice-versa.
I get the following message and the two ports are locked forever :
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c0164220 (full) cur_rx c01641e8.
Tx @base c0164208 :
9c00 0048 018d1ee2
9c00 0048 018d15e2
9c00 0048 018d1ae2
The PHY devices seem to be well configured.
Does anyone know what are the conditions to fall into this trap ?
Is it a PHY problem, a driver configuration problem or something else ?
Why does the problem not disappear when the traffic is interrupted ?
Only a board reset can reactivate the ports.
Thank you for your help.
Gérard
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Hi Gérard,
I use a 2.4.18 Linux kernel on my custom 8260 board with 3 FCC ports.
These 3 ports work fine at 100Mbs half or full duplex.
I connect 2 boards on the first port via a 10Mbs hub.
The ports auto-negotiate and fall into 10Mbs half duplex mode.
Does it mean the eth0 port has been switched from full duplex (100Mbs Switch)
to half duplex (10 Mbs Hub) by changing the Hub/Switch ?
In this case, the new duplex mode will be negotiated by the two PHYs.
But, also the MAC Controller (FCC, FPSMR(FDE) bit) must be switched to half
duplex. Otherwise, the MAC Controller continues with full duplex.
This results in late collisions. In this case, the CPCR command RESTART TRANSMIT
is necessary.
I have not seen this kind of synchronization (PHY -- MAC) in fcc_enet.c.
I don't know why.
--
--------------------------------------------------------------
Steffen Rumler
ICN CP D NT SW 7
Siemens AG
Hofmannstr. 51 Email: Steffen.Rumler@siemens.com
D-81359 Munich Phone: +49 89 722-44061
Germany Fax : +49 89 722-36703
--------------------------------------------------------------
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Steffen Rumler wrote:
I have not seen this kind of synchronization (PHY -- MAC) in fcc_enet.c.
I don't know why.
The code is there. You need a PHY interrupt to the processor when
the link status changes, then the PHY status is interrogated to set
up the MAC.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/