mpc8260 fcc enet transmit time out

Tue Jan 10 04:27:24 EST 2006

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
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
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
/
N/ETDEV 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 ) 
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/20060109/d6b86fb5/attachment.htm 