mpc8260 fcc enet transmit time out

Ho Jeffrey-r26191 r26191 at freescale.com
Tue Jan 10 13:26:59 EST 2006 

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.
 
In one of our hw, we are using realtek 10/100phy which don't have interrupt as well.
We config that phy to use the polling mode in Gianfar. We can do plug and unplug with no problem.
My suggetsion is to check how that driver do the polling and use it with your fcc_enet.

Regards, 
Jeffrey Ho 
Freescale Semiconductor HK Ltd 
Tel: 852-26668050 

 


  _____  

From: linuxppc-embedded-bounces at ozlabs.org [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of hubert.loewenguth
Sent: Tuesday, January 10, 2006 1:27 AM
To: Linuxppc-embedded at ozlabs.org
Subject: mpc8260 fcc enet transmit time out


hi the community.
I have already posted a question about my problem but it seems that nobody has encounter the same matter.
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.

I use a MPC8260 with linux 2.4.20.
The problem is with the fcc_enet driver.
I have no MII phy interrupt line with my LXT971 Phy in front of the powerpc.
Seeing that I have no interrupt line, I have configured the driver to be in half duplex, and the LXT971 too.
I'm sure that the driver is in half-duplex mode an the LXT971 too, and the auto-negociation is ok.
Everything works fine, but, if I do successive plugs/unplugs during important data transfert, The driver enter into an infinite loop:

# NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
 Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f690.
 Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
...
1c00 055c 011d486a
3c00 05ea 011d406a
 Rx @base c019f608 :
9c00 0040 01f3e000
9c00 0040 01f3e800
...
9c00 0040 01f3d000
bc00 0040 01f2f800
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
 Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f698.
 Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
1c00 05ea 011ce06a
.....

I have found, on the linux-embended forum, a personn who has the same problem:
http://ozlabs.org/pipermail/linuxppc-embedded/2001-December/005714.html <http://ozlabs.org/pipermail/linuxppc-embedded/2001-December/005714.html> 
But I'm sure about my pin connections ans so the reponse to this personn doesn't solve my problem

More interresting this one :
http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016539.html <http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016539.html> 
This personn seems to have the same troubleshouting than me .
He has tried to apply the patch provided by freescale, but it doesn't seem to correct it.

So I have had just a little piece of trace in order to see when this infernal loop appear.
I have added some trace in the fcc_enet_start_xmit .
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

    /* Some transmit errors cause the transmitter to shut
         * down.  We now issue a restart transmit.  Since the
         * errors close the BD and update the pointers, the restart
         * _should_ pick up without having to reset any of our
         * pointers either.  Also, To workaround 8260 device erratum 
         * CPM37, we must disable and then re-enable the transmitter
         * following a Late Collision, Underrun, or Retry Limit error.
         */
    

# UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
 UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
UNDERRUN ! ==> RESTART
CARRIER LOST !
........
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART

NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
 Ring data dump: cur_tx c019f778 tx_free 0 cur_rx c019f690.
 Tx @base c019f708 :
1c02 055c 012cd86a
9c00 05ea 012cd06a
9c00 05ea 012f706a
9c00 05ea 012cf06a
9c00 05ea 012cf86a
9c00 05ea 0118506a

Some personns have said me to try with 2.6 drivers but it's exactly the same problem. 
( 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
interrupt.the #define PHY_INTERRUPT condition of the 2.4 drivers version has
disapeared => with this new drivers you can't use MDIO without PHY interrupt !!
it was possible in the 2.4 version.
- seeing that the "fep->link" value is enabled only on a PHY interrupt .
I can't have this condition OK without PHY interrupt.
 "fep->link" can be asserted in the mii_parse_sr function, but has it is
indicated in the comment in the drivers :
"/* Somehow does the 971 tell me that the link is down
 * the first read after power-up.
 * read here to get a valid value in ack_int */"
That's true, the LXT 971A tell that the link is down, and seeing that I
have no interrupt, the fep->link is never asserted again.
So, I have commented the first lines of the fcc_enet_start_xmit function
which verify the value of fep->link.
I have added a #ifdef PHY_INTERRUPT condition before installing the ISR
for this interrupt.
And thanks to that, I have been able to test the new driver 2.6 .
But unfortunetly this doesn't solve my problem.)

So 2.6 driver is not the solution of my problem.

I'm asking myself if this can be due to CPM21, or CPM22, or CPM119 known bugs on mpc8260 ?
(see http://www.freescale.com/files/32bit/doc/data_sheet/MPC8260CE.pdf <http://www.freescale.com/files/32bit/doc/data_sheet/MPC8260CE.pdf>  ) but I don't think so.
Perhaps, I imagine that in fact the MPC8260 transmitter doesn't restart correctly ?
        (Also, To workaround 8260 device erratum 
         * CPM37, we must disable and then re-enable the transmitter
         * following a Late Collision, Underrun, or Retry Limit error)

Is there anybody having encounter the same problem?
Is there anybody having done some test of  numerous plug/unplug  during important data transfert with a half-duplex connection on mpc8260?
Is there anybody having an idea to help me ?

Thanks to the community for any help, I'm really desepareted here

(PS : sorry for my bad english)





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060110/23a1e836/attachment.htm

More information about the Linuxppc-embedded mailing list