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
