mpc8260 fec enet transmit time out

atul.sabharwal at exgate.tek.com atul.sabharwal at exgate.tek.com
Tue Jan 10 13:39:23 EST 2006 

How do you know that the FEC MAC & PHY are connected correctly?  Check
the CLK's generated by the PHY.

Any signal issues (with a scope) ?  Can you read/write the Phy registers
using the MDIO channel?  

 

Check the link register in the Phy if it gives any false link status?
Also, the driver might have auto switching

Of Ethernet interfaces or might have a timeout and stop any
transmit/receive which is causing the lockup.

Force the driver to re-initialize after a timeout might be a workaround.

 

--

Atul

 

________________________________

From: linuxppc-embedded-bounces at ozlabs.org
[mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of Ho
Jeffrey-r26191
Sent: Monday, January 09, 2006 6:27 PM
To: 'hubert.loewenguth'; Linuxppc-embedded at ozlabs.org
Subject: RE: mpc8260 fcc enet transmit time out

 

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
	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
	
	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 ) 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/7029fb1f/attachment.htm

More information about the Linuxppc-embedded mailing list