<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left><SPAN class=579092402-10012006><FONT face=新細明體
color=#0000ff size=2>On MPC8560 port of linuxppc-2.4, on the Gianfar driver for
TSEC and FEC, there is a mode call phy polling mode can be
enable.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=579092402-10012006><FONT face=新細明體
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=579092402-10012006><FONT face=新細明體
color=#0000ff size=2>In one of our hw, we are using realtek 10/100phy which
don't have interrupt as well.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=579092402-10012006><FONT face=新細明體
color=#0000ff size=2>We config that phy to use the polling mode in Gianfar. We
can do plug and unplug with no problem.</FONT></SPAN></DIV>
<DIV><SPAN class=579092402-10012006><FONT face=新細明體 color=#0000ff size=2>My
suggetsion is to check how that driver do the polling and use it with your
fcc_enet.</FONT></SPAN></DIV><!-- Converted from text/rtf format -->
<P><SPAN lang=en-us><FONT face=Arial size=2>Regards,</FONT></SPAN> <BR><SPAN
lang=en-us><FONT face=Arial size=2>Jeffrey Ho</FONT></SPAN> <BR><SPAN
lang=en-us><FONT face=Arial size=2>Freescale Semiconductor HK Ltd</FONT></SPAN>
<BR><SPAN lang=en-us><FONT face=Arial size=2>Tel:
852-26668050</FONT></SPAN><SPAN lang=zh-hk></SPAN> </P>
<DIV> </DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] <B>On Behalf Of
</B>hubert.loewenguth<BR><B>Sent:</B> Tuesday, January 10, 2006 1:27
AM<BR><B>To:</B> Linuxppc-embedded@ozlabs.org<BR><B>Subject:</B> mpc8260 fcc
enet transmit time out<BR></FONT><BR></DIV>
<DIV></DIV>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></BLOCKQUOTE></BODY></HTML>