<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
hi the community.<br>
I have already posted a question about my problem but it seems that
nobody has encounter the same matter.<br>
So I have made numerous tests and researches and seeing that I still
have not succeed in solving it, I try again tyo send you my bug.<br>
<br>
I use a MPC8260 with linux 2.4.20.<br>
The problem is with the fcc_enet driver.<br>
I have no MII phy interrupt line with my LXT971 Phy in front of the
powerpc.<br>
Seeing that I have no interrupt line, I have configured the driver to
be in half duplex, and the LXT971 too.<br>
I'm sure that the driver is in half-duplex mode an the LXT971 too, and
the auto-negociation is ok.<br>
Everything works fine, but, if I do successive plugs/unplugs during
important data transfert, The driver enter into an infinite loop:<br>
<br>
<i><small># NETDEV WATCHDOG: eth0: transmit timed out<br>
eth0: transmit timed out.<br>
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f690.<br>
Tx @base c019f708 :<br>
1c00 055c 011cd06a<br>
5c00 003b 011cd86a<br>
...<br>
1c00 055c 011d486a<br>
3c00 05ea 011d406a<br>
Rx @base c019f608 :<br>
9c00 0040 01f3e000<br>
9c00 0040 01f3e800<br>
...<br>
9c00 0040 01f3d000<br>
bc00 0040 01f2f800<br>
NETDEV WATCHDOG: eth0: transmit timed out<br>
eth0: transmit timed out.<br>
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f698.<br>
Tx @base c019f708 :<br>
1c00 055c 011cd06a<br>
5c00 003b 011cd86a<br>
1c00 05ea 011ce06a<br>
.....<br>
<br>
</small></i>I have found, on the linux-embended forum, a personn who
has the same
problem:<br>
<font color="#3333ff"><a class="moz-txt-link-freetext"
href="http://ozlabs.org/pipermail/linuxppc-embedded/2001-December/005714.html">http://ozlabs.org/pipermail/linuxppc-embedded/2001-December/005714.html</a></font><br>
But I'm sure about my pin connections ans so the reponse to this
personn doesn't solve my problem<br>
<br>
More interresting this one :<br>
<font color="#3333ff"><a class="moz-txt-link-freetext"
href="http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016539.html">http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016539.html</a></font><br>
This personn seems to have the same troubleshouting than me .<br>
He has tried to apply the patch provided by freescale, but it doesn't
seem to correct it.<br>
<i><small><br>
</small></i>So I have had just a little piece of trace in order to see
when this
infernal loop appear.<br>
I have added some trace in the fcc_enet_start_xmit .<br>
has you know, after some kind of transmit errors, the transmitter need
to be restarted, and so I have added some traces to see when it is
restarted<br>
<br>
/* Some transmit errors cause the transmitter to shut<br>
* down. We now issue a restart transmit. Since the<br>
* errors close the BD and update the pointers, the restart<br>
* _should_ pick up without having to reset any of our<br>
* pointers either. Also, To workaround 8260 device erratum <br>
* CPM37, we must disable and then re-enable the transmitter<br>
* following a Late Collision, Underrun, or Retry Limit error.<br>
*/<br>
<br>
<br>
<small><big><small><big><font color="#000000"><small>#</small></font></big></small></big></small><small><big><small><big><font
color="#000000"><small>
UNDERRUN ! ==> RESTART<br>
CARRIER LOST !<br>
CARRIER LOST !<br>
</small></font></big></small></big></small><small><big><small><big><font
color="#000000"><small> UNDERRUN ! ==> RESTART<br>
CARRIER LOST !<br>
CARRIER LOST !<br>
UNDERRUN ! ==> RESTART<br>
UNDERRUN ! ==> RESTART<br>
CARRIER LOST !<br>
........<br>
CARRIER LOST !<br>
CARRIER LOST !<br>
UNDERRUN ! ==> RESTART<br>
CARRIER LOST !<br>
CARRIER LOST !<br>
CARRIER LOST !<br>
CARRIER LOST !<br>
CARRIER LOST !<br>
CARRIER LOST !<br>
CARRIER LOST !<br>
UNDERRUN ! ==> RESTART<br>
<i><br>
N</i>ETDEV WATCHDOG: eth0: transmit timed out<br>
eth0: transmit timed out.<br>
Ring data dump: cur_tx c019f778 tx_free 0 cur_rx c019f690.<br>
Tx @base c019f708 :<br>
1c02 055c 012cd86a<br>
9c00 05ea 012cd06a<br>
9c00 05ea 012f706a<br>
9c00 05ea 012cf06a<br>
9c00 05ea 012cf86a<br>
9c00 05ea 0118506a</small></font></big></small></big></small><br>
<i><small><br>
</small></i>Some personns have said me to try with 2.6 drivers but it's
exactly the same problem. <br>
( even if I'm a little bit surprised to see that with the 2.6 version
drivers seems to be uncompatible with boards wich use MDIO without PHY<br>
interrupt.the #define PHY_INTERRUPT condition of the 2.4 drivers
version has<br>
disapeared => with this new drivers you can't use MDIO without PHY
interrupt !!<br>
it was possible in the 2.4 version.<br>
- seeing that the "fep->link" value is enabled only on a PHY
interrupt .<br>
I can't have this condition OK without PHY interrupt.<br>
"fep->link" can be asserted in the mii_parse_sr function, but has
it is<br>
indicated in the comment in the drivers :<br>
"/* Somehow does the 971 tell me that the link is down<br>
* the first read after power-up.<br>
* read here to get a valid value in ack_int */"<br>
That's true, the LXT 971A tell that the link is down, and seeing that I<br>
have no interrupt, the fep->link is never asserted again.<br>
So, I have commented the first lines of the fcc_enet_start_xmit function<br>
which verify the value of fep->link.<br>
I have added a #ifdef PHY_INTERRUPT condition before installing the ISR<br>
for this interrupt.<br>
And thanks to that, I have been able to test the new driver 2.6 .<br>
But unfortunetly this doesn't solve my problem.)<br>
<br>
So 2.6 driver is not the solution of my problem.<br>
<br>
I'm asking myself if this can be due to CPM21, or CPM22, or CPM119
known bugs on mpc8260 ?<br>
(see <a class="moz-txt-link-freetext"
href="http://www.freescale.com/files/32bit/doc/data_sheet/MPC8260CE.pdf">http://www.freescale.com/files/32bit/doc/data_sheet/MPC8260CE.pdf</a>
) but I don't think so.<br>
Perhaps, I imagine that in fact the MPC8260 transmitter doesn't restart
correctly ?<br>
(Also, To workaround 8260 device erratum <br>
* CPM37, we must disable and then re-enable the transmitter<br>
* following a Late Collision, Underrun, or Retry Limit error)<br>
<br>
Is there anybody having encounter the same problem?<br>
Is there anybody having done some test of numerous plug/unplug during
important data transfert with a half-duplex connection on mpc8260?<br>
Is there anybody having an idea to help me ?<br>
<br>
Thanks to the community for any help, I'm really desepareted here<br>
<br>
(PS : sorry for my bad english)<br>
<br>
<br>
<br>
</body>
</html>