FCC1 failing on large packet PINGS, while FCC2 is successful

FCC1 failing on large packet PINGS, while FCC2 is successful

[embedded]

We've found a way to get ping to fail all of the time by increasing
the size of the ping messages.  When we use the max in Windows of
65500, every ping to the first FCC1 Ethernet is dropped.  However,
when we ping with a size of 65500 to the second FCC2 Ethernet
everything is fine and all echos are successful.

In windows:
ping -l 64000 172.24.100.11  -t

It definitely seems to be a problem with the mpc, but I'm not sure
where to look.  Board? KErnel? boot loader?  The two Ethernet devices
should be configured identically, and looking through the kernel code,
it seems that there aren't any preferred treatment differences.  Could
the problem be in the bit-banging mdio control, or should I look
within fs_enet?  We've got this reproducing on all of our boards and
it could also reside in the board setup...

Does anyone with experience on the ep8248 and/or mpc8272 family,
fs_enet-* code have any ideas where I should look next?

-Alan


FCC1/2 registers
=============
gfmr1: 0x2000003c
fpsmr1: 0x14000080
ftodr1: 0x1400
fdsr1: 0xd555
fcce1: 0x00080100
fccm1: 0x001b0000
fccs1: 0x00
ftirr1_phy0: 0x00
ftirr1_phy1: 0x00
ftirr1_phy2: 0x00
ftirr1_phy3: 0x00
gfmr2: 0x2000003c
fpsmr2: 0x14000080
ftodr2: 0x1400
fdsr2: 0xd555
fcce2: 0x00080100
fccm2: 0x001b0000
fccs2: 0x00
ftirr2_phy0: 0x00
ftirr2_phy1: 0x00
ftirr2_phy2: 0x00
ftirr2_phy3: 0x00

FCC1/2 PRAM
=================
e0008400 : 0x0180  RIPTR
e0008402 : 0x01a0  TIPTR
e0008404 : 0x0000  ----
e0008406 : 0x0600  MRBLR (maximum receive buffer length
e0008408 : 0x30a0  RSTATE(receive internal state
e000840a : 0x0000
e000840c : 0x0795  RBASE
e000840e : 0xe000
e0008410 : 0x2c80  RBDSTAT      ---------now 8400   went to 8c00
e0008412 : 0x0040  RBDLEN
e0008414 : 0x0796  RBDPTR
e0008416 : 0x1010
e0008418 : 0x3004  TSTATE
e000841a : 0x0000
e000841c : 0x0795  TBASE
e000841e : 0xe100
e0008420 : 0x0000  TBDSTAT
e0008422 : 0x0000  TBDLEN
e0008424 : 0x0000  TDPTR
e0008426 : 0x0000
e0008428 : 0x0795  RBPTR
e000842a : 0xe0f8
e000842c : 0x0795  TBPTR
e000842e : 0xe100
e0008430 : 0xdebb  RCRC
e0008432 : 0x20e3
e0008434 : 0xffff  ----
e0008436 : 0xffff  ----
e0008438 : 0x0000  TCRC
e000843a : 0x0000
e000843c : 0x0000  ----
e000843e : 0x0000  ----

e0008500 : 0x0200  RIPTR
e0008502 : 0x0220  TIPTR
e0008504 : 0x0000  ----
e0008506 : 0x0600  MRBLR (maximum receive buffer length
e0008508 : 0x30a0  RSTATE(receive internal state
e000850a : 0x0000
e000850c : 0x0796  RBASE
e000850e : 0x2000
e0008510 : 0x0c80  RBDSTAT         now 8400  now 8c00
e0008512 : 0x0040  RBDLEN
e0008514 : 0x07b1  RBDPTR
e0008516 : 0xc010
e0008518 : 0x3004  TSTATE
e000851a : 0x0000
e000851c : 0x0796  TBASE
e000851e : 0x2100
e0008520 : 0x0000  TBDSTAT
e0008522 : 0x0000  TBDLEN
e0008524 : 0x0000  TDPTR
e0008526 : 0x0000
e0008528 : 0x0796  RBPTR
e000852a : 0x2018
e000852c : 0x0796  TBPTR
e000852e : 0x2100
e0008530 : 0xdebb  RCRC
e0008532 : 0x20e3
e0008534 : 0xffff  ----
e0008536 : 0xffff  ----
e0008538 : 0x0000  TCRC
e000853a : 0x0000
e000853c : 0x0000  ----
e000853e : 0x0000  ----

Re: FCC1 failing on large packet PINGS, while FCC2 is successful

[Scott Wood]

embedded wrote:
> We've found a way to get ping to fail all of the time by increasing
> the size of the ping messages.  When we use the max in Windows of
> 65500, every ping to the first FCC1 Ethernet is dropped.  However,
> when we ping with a size of 65500 to the second FCC2 Ethernet
> everything is fine and all echos are successful.
> 
> In windows:
> ping -l 64000 172.24.100.11  -t
> 
> It definitely seems to be a problem with the mpc, but I'm not sure
> where to look.  Board? KErnel? boot loader?  The two Ethernet devices
> should be configured identically, and looking through the kernel code,
> it seems that there aren't any preferred treatment differences.  Could
> the problem be in the bit-banging mdio control, or should I look
> within fs_enet?  We've got this reproducing on all of our boards and
> it could also reside in the board setup...
> 
> Does anyone with experience on the ep8248 and/or mpc8272 family,
> fs_enet-* code have any ideas where I should look next?

It looks very similar to what I was seeing on ep8248 -- the first 
ethernet port would fail when attempting to receive back-to-back 
packets.  I didn't look into it too closely since I thought it was 
probably a board issue (I had only one, and the firmware never generated 
any traffic that resulted in back-to-back receives).

I'd be very interested if you ever figure out what's wrong.

-Scott

Re: FCC1 failing on large packet PINGS, while FCC2 is successful

[embedded]

Actually, it may have been a simple fix.  Looking at the clocks. We
noticed something a little awry;  Just rechecking the RM and the code
we found that within ep8248.c, the clock setup code had the RX and TX
clocks flipped.

FCC1 RX CLK should be Clock 10
FCC1 TX CLK should be Clock 11

in: arch/powerpc/platforms/82xx/ep8248.c
static void __init init_ioports(void)

-	cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK11, CPM_CLK_RX);
-	cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_TX);

+	cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_RX);
+	cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK11, CPM_CLK_TX);

-Alan


On Mon, Sep 29, 2008 at 8:43 AM, Scott Wood <scottwood@freescale.com> wrote:
> embedded wrote:
>>
>> We've found a way to get ping to fail all of the time by increasing
>> the size of the ping messages.  When we use the max in Windows of
>> 65500, every ping to the first FCC1 Ethernet is dropped.  However,
>> when we ping with a size of 65500 to the second FCC2 Ethernet
>> everything is fine and all echos are successful.
>>
>> In windows:
>> ping -l 64000 172.24.100.11  -t
>>
>> It definitely seems to be a problem with the mpc, but I'm not sure
>> where to look.  Board? KErnel? boot loader?  The two Ethernet devices
>> should be configured identically, and looking through the kernel code,
>> it seems that there aren't any preferred treatment differences.  Could
>> the problem be in the bit-banging mdio control, or should I look
>> within fs_enet?  We've got this reproducing on all of our boards and
>> it could also reside in the board setup...
>>
>> Does anyone with experience on the ep8248 and/or mpc8272 family,
>> fs_enet-* code have any ideas where I should look next?
>
> It looks very similar to what I was seeing on ep8248 -- the first ethernet
> port would fail when attempting to receive back-to-back packets.  I didn't
> look into it too closely since I thought it was probably a board issue (I
> had only one, and the firmware never generated any traffic that resulted in
> back-to-back receives).
>
> I'd be very interested if you ever figure out what's wrong.
>
> -Scott
>

Re: FCC1 failing on large packet PINGS, while FCC2 is successful

[Scott Wood]

embedded wrote:
> Actually, it may have been a simple fix.  Looking at the clocks. We
> noticed something a little awry;  Just rechecking the RM and the code
> we found that within ep8248.c, the clock setup code had the RX and TX
> clocks flipped.
> 
> FCC1 RX CLK should be Clock 10
> FCC1 TX CLK should be Clock 11

D'oh!  Thanks for finding that.

> in: arch/powerpc/platforms/82xx/ep8248.c
> static void __init init_ioports(void)
> 
> -	cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK11, CPM_CLK_RX);
> -	cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_TX);
> 
> +	cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_RX);
> +	cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK11, CPM_CLK_TX);

Acked-by: Scott Wood <scottwood@freescale.com>

Post to linuxppc-dev@ozlabs.org and galak@kernel.crashing.org with a 
Signed-off-by.

-Scott