8260 FCC Ethernet problem

[Leitner, Kip]

Rune,
 
I just found your post regarding the Local_Protect_Bit not being set in
8260 FCC, for "some versions of 2.4 source " fcc_enet.c, and this
causing problems.  In my situation, we are getting late collision errors
in our application, details follow (after your patch notes).  
 
We are wondering if we apply your patch to 2.4.18 fcc_enet.c, will this
fix our late collision problem, as 2.4.18 fcc_enet.c has the uncorrected
part of the code in our Linux distribution that your patch fixes.
 
Sincerely,
 
Kip Leitner   
 
**************
<Rune Wrote >
 
I just found that there is a problem in the FCC driver.
This was fixed in some versions of the 2.4 source....
 
Th Local Protect Bit is not set when enterring Full Duplex mode. This
causes the FCC to turn off the transmitter when packets are received,
and also
causes NonOctet frame errors and CRC errors (late collission)
 
This diff is agains the 2.6.7 sources, but should apply cleanly against
top of source.
 
===== arch/ppc/8260_io/fcc_enet.c 1.20 vs edited =====
--- 1.20/arch/ppc/8260_io/fcc_enet.c    2004-07-06 16:44:29 -05:00
+++ edited/arch/ppc/8260_io/fcc_enet.c  2004-09-10 14:44:05 -05:00
@@ -2013,9 +2013,9 @@
        fccp = fcp->fccp;
 
        if (duplex)
-               fccp->fcc_fpsmr |= FCC_PSMR_FDE;
+               fccp->fcc_fpsmr |= FCC_PSMR_FDE | FCC_PSMR_LPB;
        else
-               fccp->fcc_fpsmr &= ~FCC_PSMR_FDE;
+               fccp->fcc_fpsmr &= ~(FCC_PSMR_FDE | FCC_PSMR_LPB);
 
        /* Enable transmit/receive */
        fccp->fcc_gfmr |= FCC_GFMR_ENR | FCC_GFMR_ENT;
 
 
Rune Torgersen
System Developer
Innovative Systems LLC
1000 Innovative Drive
Mitchell, SD 57301
Ph: 605-995-6120
www.innovsys.com

 

**************

< Dump  from Kip Leitner > 

 

In kernel version 2.4.18, in the Ethernet driver fcc_enet.c, we hit the
ring data dump with text message "eth0: transmit timeout".  Upon
inspection of the buffer descriptors, we noticed that buffer four (4,
0-based numbering) shows status for a late collision.  Our lan
conditions at the time of the dump:  PHY running at 10 Base T,
half-duplex, connected to half-duplex hub.  We know (from our high-level
software) that while we were continuously transmitting, we also began to
receive packets, which is when this repeatable condition of the Ring
Dump occurred. Dump below (more text after):

 

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                    ** Late Collision **

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

9c00 0040 0046f800

9c00 0040 0046e000

9c00 0072 0046e800

9c00 0072 0046d000

9c00 0072 0046d800

9c00 0072 0046c000

9c00 0072 0046c800

9c00 0072 0046b000

9c00 0072 0046b800

9c00 0072 0046a000

9c00 0040 0046a800

9c00 0072 00469000

9c00 0072 00469800

9c00 0072 00468000

9c00 0072 00468800

9c00 0072 00467000

9c00 0040 00467800

9c00 0072 00466000

9c00 0040 00466800

9c00 0072 00465000

9c00 0040 00465800

9c00 0040 00464000

9c00 0040 00464800

9c00 0040 00463000

9c00 0040 00463800

9c00 0040 00462000

9c00 0040 00462800

9c00 0040 00461000

9c00 0040 00461800

9c00 0040 00460000

bc00 0040 00460800   

 

We are wondering if our hardware (we build our own) has a problem, our
physical network has a problem, and/or if 

 

--> the driver supports recovery from late collisions.  

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20050726/37d225a1/attachment.htm>