mpc8260 fcc enet transmit time out

mpc8260 fcc enet transmit time out

[hubert.loewenguth]

[-- Attachment #1: Type: text/plain, Size: 5321 bytes --]

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)




[-- Attachment #2: Type: text/html, Size: 7298 bytes --]

RE: mpc8260 fcc enet transmit time out

[Ho Jeffrey-r26191]

[-- Attachment #1: Type: text/plain, Size: 6248 bytes --]

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@ozlabs.org [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of hubert.loewenguth
Sent: Tuesday, January 10, 2006 1:27 AM
To: Linuxppc-embedded@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)






[-- Attachment #2: Type: text/html, Size: 9656 bytes --]

mpc8260 fcc enet transmit time out

[Hunter, David]

One day, hubert.loewenguth at thales-bm.com wrote:
> Everything works fine, but, if I do successive plugs/unplugs during=20
> important data transfert, The driver enter into an infinite loop:
> ...
> Is there anybody having encounter the same problem?
> Is there anybody having done some test of  numerous plug/unplug
during=20
> important data transfert with a half-duplex connection on mpc8260?
> Is there anybody having an idea to help me ?

I have seen many symptoms involving the "NETDEV WATCHDOG: eth0: transmit
timed out" message, but so far I do not have a code fix for any of them.
:(

We (my employer) use an MPC8270 (mask 2K49M) and LXT971A PHY, with Linux
2.4.18.  In our case we do have MII PHY interrupt.  Like you, when I get
the transmit timeout, it repeats forever.  But I do not see the problem
when doing successive plugs/unplugs of the Ethernet cable.  Instead, I
get timeout during normal board operation, without human interaction.

In one customer site where our MPC8270 board is used, the customer uses
100 Mb half duplex Ethernet.  During many weeks of normal operation,
several times the board did experience transmit timeout.  One of the
times, this was output:

<-------- DUMP STARTS HERE ---------->
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
 Ring data dump: cur_tx c01aa380 (full) cur_rx c01aa220.
 Tx @base c01aa308 :
9c00 0051 070f79a2
1c00 0056 070f7da2
1c00 0056 070f7ea2
1c00 0051 070f7ba2
1c80 003f 070f51c2
9c00 0056 070f50c2
9c00 0051 070f52c2
9c00 0056 070f53c2
9c00 0056 070f55c2
9c00 0051 070f54c2
dc00 0038 070f56c2
9c00 0056 070f57c2
9c00 0051 070f58c2
9c00 0056 070f59c2
9c00 0056 070f5ac2
bc00 0056 070f7ca2
 Rx @base c01aa208 :
9c00 0040 0046f000
<--- snip: BD status are all 9c00 -->
9c00 0040 00461000
9c00 0040 00461800
9c00 0040 00460000
bc00 0040 00460800
<---------- DUMP ENDS HERE ---------->

Note that one TxBD has the status 0x1c80, indicating late collision
(BD_ENET_TX_LC).  This is an unusual condition in Ethernet, but recovery
should still be possible.  Like you, I suspect errata CPM 119, but I
have not tried the patch yet.  (Development schedules and all that
jazz.)

As a workaround, we placed a 10/100 Mb hub between the board and the
customer's network, which negotiated the PHY up to 100 Mb full duplex.
The transmit timeout problem has not been seen since (to the best of my
knowledge.)

Back in the lab I have been able to reproduce the transmit timeout on a
100 Mb full duplex network.  Like you, I added printk output where
fcc_enet_interrupt tests each BD_ENET_TX_* flag.  In one case, I saw
this:

<-------- DUMP STARTS HERE ---------->
eth0: BDP=3Dc01aa370: Carrier lost
eth0: BDP=3Dc01aa370: Carrier lost
eth0: BDP=3Dc01aa330: Carrier lost
eth0: BDP=3Dc01aa360: Carrier lost
eth0: BDP=3Dc01aa348: Carrier lost
eth0: BDP=3Dc01aa310: Carrier lost
eth0: BDP=3Dc01aa318: Carrier lost
<---- Carrier lost repeats 61 more times, random BDP ---->
eth0: BDP=3Dc01aa348: Underrun
eth0: Restarting transmitter!!!

NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
<-------- DUMP ENDS HERE ---------->

The Underrun message means TxBD status bit BD_ENET_TX_UN (0x0002) was
set.  The last Tx ring data dump in your post shows the same thing.
That scares me, mainly because I don't know what it means.  Does it mean
the SDMA transfer didn't end on time?  I dunno.  And what the heck is
carrier lost during TX in full duplex mode?  It makes sense for half
duplex mode like your situation, but I can't make sense of it for full
duplex.  Further, the underrun case has only happened once; in most
other cases, I get a transmit timeout wih absolutely no TxBD error bits
whatsoever, and no indication that a TX restart was even attempted.
That's even scarier.  I also did try repeated plug/unplug of Ethernet
during peak normal operation (probably 5-10 Mb traffic) on the 100 Mb
full duplex network, but after 11 successive plugs I did not see any
timeouts.

I'm starting to wonder if I have a cache coherency problem.  The buffer
descriptors are in main RAM and the data cache is turned on...  Its just
a thought I picked up reading some prior posts that I can't rightly
recall.

I noted that the MPC8280 manual (online from Freescale) does now detail
the transmitter recovery procedure (section 30.10.1 FCC Transmit
Errors), and it's not nearly as simple as what fcc_enet.c implements in
any kernel version.  Despite CPM37, they don't toggle GFMR[ENT] in
combination with the RESTART_TX command.  Also, in 30.12.1 FCC
Transmitter Full Sequence, a command (either RESTART_TX or INIT_TRX)
must be issued after GFMR[ENT] is cleared but _before_ it is set.  You
might try changing fcc_enet_interrupt to do this:

	    if (must_restart) {
		volatile cpm8260_t *cp;

		cep->fccp->fcc_gfmr &=3D ~FCC_GFMR_ENT;

		cp =3D cpmp;
		cp->cp_cpcr =3D
		    mk_cr_cmd(cep->fip->fc_cpmpage,
cep->fip->fc_cpmblock,
		    		0x0c, CPM_CR_RESTART_TX) | CPM_CR_FLG;
		while (cp->cp_cpcr & CPM_CR_FLG);

		cep->fccp->fcc_gfmr |=3D  FCC_GFMR_ENT;
	    }

I've not been able to work on the problem for some time (development
schedules and all that jazz), but I'll post my solution if I find one.

-Dave


DISCLAIMER:
Important Notice *************************************************
This e-mail may contain information that is confidential, privileged or =
otherwise protected from disclosure. If you are not an intended =
recipient of this e-mail, do not duplicate or redistribute it by any =
means. Please delete it and any attachments and notify the sender that =
you have received it in error. Unintended recipients are prohibited from =
taking action on the basis of information in this e-mail.E-mail messages =
may contain computer viruses or other defects, may not be accurately =
replicated on other systems, or may be intercepted, deleted or =
interfered with without the knowledge of the sender or the intended =
recipient. If you are not comfortable with the risks associated with =
e-mail messages, you may decide not to use e-mail to communicate with =
IPC. IPC reserves the right, to the extent and under circumstances =
permitted by applicable law, to retain, monitor and intercept e-mail =
messages to and from its systems.

Re: mpc8260 fcc enet transmit time out

[hubert.loewenguth]

hello David and the community

So happy to see that I'm not alone against this matter :)

/I've not been able to work on the problem for some time (development
schedules and all that jazz)...

/Same situation :), but I will try your solution next week and send you i=
f it fix the problem /
/

Hubert loewenguth


Hunter, David a =E9crit :

>One day, hubert.loewenguth at thales-bm.com wrote:
> =20
>
>>Everything works fine, but, if I do successive plugs/unplugs during=20
>>important data transfert, The driver enter into an infinite loop:
>>...
>>Is there anybody having encounter the same problem?
>>Is there anybody having done some test of  numerous plug/unplug
>>   =20
>>
>during=20
> =20
>
>>important data transfert with a half-duplex connection on mpc8260?
>>Is there anybody having an idea to help me ?
>>   =20
>>
>
>I have seen many symptoms involving the "NETDEV WATCHDOG: eth0: transmit=

>timed out" message, but so far I do not have a code fix for any of them.=

>:(
>
>We (my employer) use an MPC8270 (mask 2K49M) and LXT971A PHY, with Linux=

>2.4.18.  In our case we do have MII PHY interrupt.  Like you, when I get=

>the transmit timeout, it repeats forever.  But I do not see the problem
>when doing successive plugs/unplugs of the Ethernet cable.  Instead, I
>get timeout during normal board operation, without human interaction.
>
>In one customer site where our MPC8270 board is used, the customer uses
>100 Mb half duplex Ethernet.  During many weeks of normal operation,
>several times the board did experience transmit timeout.  One of the
>times, this was output:
>
><-------- DUMP STARTS HERE ---------->
>NETDEV WATCHDOG: eth0: transmit timed out
>eth0: transmit timed out.
> Ring data dump: cur_tx c01aa380 (full) cur_rx c01aa220.
> Tx @base c01aa308 :
>9c00 0051 070f79a2
>1c00 0056 070f7da2
>1c00 0056 070f7ea2
>1c00 0051 070f7ba2
>1c80 003f 070f51c2
>9c00 0056 070f50c2
>9c00 0051 070f52c2
>9c00 0056 070f53c2
>9c00 0056 070f55c2
>9c00 0051 070f54c2
>dc00 0038 070f56c2
>9c00 0056 070f57c2
>9c00 0051 070f58c2
>9c00 0056 070f59c2
>9c00 0056 070f5ac2
>bc00 0056 070f7ca2
> Rx @base c01aa208 :
>9c00 0040 0046f000
><--- snip: BD status are all 9c00 -->
>9c00 0040 00461000
>9c00 0040 00461800
>9c00 0040 00460000
>bc00 0040 00460800
><---------- DUMP ENDS HERE ---------->
>
>Note that one TxBD has the status 0x1c80, indicating late collision
>(BD_ENET_TX_LC).  This is an unusual condition in Ethernet, but recovery=

>should still be possible.  Like you, I suspect errata CPM 119, but I
>have not tried the patch yet.  (Development schedules and all that
>jazz.)
>
>As a workaround, we placed a 10/100 Mb hub between the board and the
>customer's network, which negotiated the PHY up to 100 Mb full duplex.
>The transmit timeout problem has not been seen since (to the best of my
>knowledge.)
>
>Back in the lab I have been able to reproduce the transmit timeout on a
>100 Mb full duplex network.  Like you, I added printk output where
>fcc_enet_interrupt tests each BD_ENET_TX_* flag.  In one case, I saw
>this:
>
><-------- DUMP STARTS HERE ---------->
>eth0: BDP=3Dc01aa370: Carrier lost
>eth0: BDP=3Dc01aa370: Carrier lost
>eth0: BDP=3Dc01aa330: Carrier lost
>eth0: BDP=3Dc01aa360: Carrier lost
>eth0: BDP=3Dc01aa348: Carrier lost
>eth0: BDP=3Dc01aa310: Carrier lost
>eth0: BDP=3Dc01aa318: Carrier lost
><---- Carrier lost repeats 61 more times, random BDP ---->
>eth0: BDP=3Dc01aa348: Underrun
>eth0: Restarting transmitter!!!
>
>NETDEV WATCHDOG: eth0: transmit timed out
>eth0: transmit timed out.
><-------- DUMP ENDS HERE ---------->
>
>The Underrun message means TxBD status bit BD_ENET_TX_UN (0x0002) was
>set.  The last Tx ring data dump in your post shows the same thing.
>That scares me, mainly because I don't know what it means.  Does it mean=

>the SDMA transfer didn't end on time?  I dunno.  And what the heck is
>carrier lost during TX in full duplex mode?  It makes sense for half
>duplex mode like your situation, but I can't make sense of it for full
>duplex.  Further, the underrun case has only happened once; in most
>other cases, I get a transmit timeout wih absolutely no TxBD error bits
>whatsoever, and no indication that a TX restart was even attempted.
>That's even scarier.  I also did try repeated plug/unplug of Ethernet
>during peak normal operation (probably 5-10 Mb traffic) on the 100 Mb
>full duplex network, but after 11 successive plugs I did not see any
>timeouts.
>
>I'm starting to wonder if I have a cache coherency problem.  The buffer
>descriptors are in main RAM and the data cache is turned on...  Its just=

>a thought I picked up reading some prior posts that I can't rightly
>recall.
>
>I noted that the MPC8280 manual (online from Freescale) does now detail
>the transmitter recovery procedure (section 30.10.1 FCC Transmit
>Errors), and it's not nearly as simple as what fcc_enet.c implements in
>any kernel version.  Despite CPM37, they don't toggle GFMR[ENT] in
>combination with the RESTART_TX command.  Also, in 30.12.1 FCC
>Transmitter Full Sequence, a command (either RESTART_TX or INIT_TRX)
>must be issued after GFMR[ENT] is cleared but _before_ it is set.  You
>might try changing fcc_enet_interrupt to do this:
>
>	    if (must_restart) {
>		volatile cpm8260_t *cp;
>
>		cep->fccp->fcc_gfmr &=3D ~FCC_GFMR_ENT;
>
>		cp =3D cpmp;
>		cp->cp_cpcr =3D
>		    mk_cr_cmd(cep->fip->fc_cpmpage,
>cep->fip->fc_cpmblock,
>		    		0x0c, CPM_CR_RESTART_TX) | CPM_CR_FLG;
>		while (cp->cp_cpcr & CPM_CR_FLG);
>
>		cep->fccp->fcc_gfmr |=3D  FCC_GFMR_ENT;
>	    }
>
>I've not been able to work on the problem for some time (development
>schedules and all that jazz), but I'll post my solution if I find one.
>
>-Dave
>
>
>DISCLAIMER:
>Important Notice *************************************************
>This e-mail may contain information that is confidential, privileged or =
otherwise protected from disclosure. If you are not an intended recipient=
 of this e-mail, do not duplicate or redistribute it by any means. Please=
 delete it and any attachments and notify the sender that you have receiv=
ed it in error. Unintended recipients are prohibited from taking action o=
n the basis of information in this e-mail.E-mail messages may contain com=
puter viruses or other defects, may not be accurately replicated on other=
 systems, or may be intercepted, deleted or interfered with without the k=
nowledge of the sender or the intended recipient. If you are not comforta=
ble with the risks associated with e-mail messages, you may decide not to=
 use e-mail to communicate with IPC. IPC reserves the right, to the exten=
t and under circumstances permitted by applicable law, to retain, monitor=
 and intercept e-mail messages to and from its systems.
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> =20
>