MPC5200 ethernet communication stops unexpected

[David Kanceruk]

Hi Eberhard,

    I have the problem with corrupted data on the MPC5200B. I traced the
problem to the BestComm driver. I see the correct data in the socket buffer
for the icmp reply but when BestComm puts the data into the Tx FIFO of the
fec, it sometimes puts the wrong byte in location 0 (which corrupts the
ethernet destination address) or location 62 (which corrupts the ping data).
These locations are always the same locations. Here is the contents of some
sample buffers I captured after gracefully stopping the fec transmitter (so
I could examine the FIFO without the fec doing a reset):

icmp csum = 7c2b
skb->data = 14
skb->dst->output = c0175924
neigh_hh_output calls = c0162b20
calling neigh->ops->queue_xmit c015c360
calling q->enqueue c0168034
dev->hard_start_xmit = c013ff3c
before - fec_hard_start_xmit 1 skb->data = 14      ----------------- this is
at offset 62
after - fec_hard_start_xmit 1 skb->data = 14         ----------------- still
has the correct value
start_addr = 00000160, end_addr = 000001C6, buf_len = 00000066
FEC IEVENT- 00000000
00003923 CD3F0050 C2263023 08004500  ----------------- this is what is in
the fec Tx FIFO
005437E3 00004001 BF72C0A8 0102C0A8
01010000 7C2B064A 000405C4 27466579
00000809 0A0B0C0D 0E0F1011 12130015   ---------------- second last byte is
00 --- this is bad!
16171819 1A1B1C1D 1E1F2021 22232425
26272829 2A2B2C2D 2E2F3031 32333435
FEC IEVENT- 00000000
icmp csum = 3a2a
skb->data = 14
skb->dst->output = c0175924
neigh_hh_output calls = c0162b20
calling neigh->ops->queue_xmit c015c360
calling q->enqueue c0168034
dev->hard_start_xmit = c013ff3c
before - fec_hard_start_xmit 1 skb->data = 14
after - fec_hard_start_xmit 1 skb->data = 14
start_addr = 000001C6, end_addr = 0000022C, buf_len = 00000066
FEC IEVENT- 00000000
00003923 CD3F0050 C2263023 08004500
005437E4 00004001 BF71C0A8 0102C0A8
01010000 3A2A064A 000506C4 2746A679
00000809 0A0B0C0D 0E0F1011 12131415   ---------------- second last byte is
14 --- this is good this time!
16171819 1A1B1C1D 1E1F2021 22232425
26272829 2A2B2C2D 2E2F3031 32333435
FEC IEVENT- 00000000

I think we need to focus on how the BestComm driver works now. I wonder if
there are any experts out there that might know what could be wrong?

Best regards,

Dave

On 4/27/07, Eberhard Stoll <eberhard.stoll at berghof.com> wrote:
>
> Hi,
> >      Do your boards use the MPC5200B or MPC5200? Also, do you ever see
> > any corrupted data? (I'm guessing you would have mentioned it if you
> > did see corrupted data)
> I use MPC5200B processors. With MPC5200(A) processors i don't get this
> error!
> I didn't recognize corrupted data 'til now. But this could be - now i'm
> sending only pings and sometimes get output like this on the console:
> -- 8< --
>
> ..............................................................................tcp_recheck_csum:
> seq 0x5881325f retransmit, csum 0x232b OK?
> .............................................tcp_recheck_csum: seq
> 0x58813dd6 retransmit, csum 0xd1ad OK?
> ...............tcp_recheck_csum: seq 0x58814286 retransmit, csum 0xee5b
> OK?
> .....................tcp_recheck_csum: seq 0x58814982 retransmit, csum
> 0x8528 OK?
> ..............................................tcp_recheck_csum: seq
> 0x58815601 retransmit, csum 0x6ee1 OK?
> -- 8< --
> but i don't know what it means and where it comes from. Does someone know?
>
> Eberhard
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
David Kanceruk

"The generation of random numbers is far too important to be left to
chance."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070427/afb8de9f/attachment.htm