netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matheos Worku <Matheos.Worku@Sun.COM>
To: Rick Jones <rick.jones2@hp.com>
Cc: Chris Friesen <cfriesen@nortel.com>, netdev@vger.kernel.org
Subject: Re: sun neptune mis-detecting ethernet crc faults?
Date: Mon, 29 Jun 2009 16:13:53 -0700	[thread overview]
Message-ID: <4A494AB1.7010407@sun.com> (raw)
In-Reply-To: <4A493222.4040504@hp.com>

Rick Jones wrote:
> Chris Friesen wrote:
>> Hi all,
>>
>> David Miller is busy and suggested someone on the list might be able to
>> help.
>>
>> We have some boards using the Sun Neptune ethernet adapters. We're
>> seeing behaviour that at this point looks like a hardware glitch
>> in the ethernet CRC validation on the receive path. It appears to be
>> incorrectly detecting a corrupt CRC and dropping the frames. (We've
>> enabled port mirroring on the switch and the frames are received without
>> errors on the eavesdropper board.)
>
> A simplistic question, but are you sure that the eavesdropper board is 
> checking CRCs?
>
>> The odd thing is that we're using a TCP connection and once the CRC
>> glitch shows up for a particular chunk of data it continues to drop all
>> the retransmissions for that chunk as having bad CRCs, even though their
>> CRC values are totally different due to different embedded timestamps.
>
> Do you mean TCP timestamp options?
>
>> Has anyone heard of anything like this on the Neptune hardware?
At Sun, we haven't seen such RX CRC error before.
>
> Can't say as I have, but the history of "networking" is littered with 
> data pattern induced bugs in all manner of hardware.
>
>> MTU is set to 2000 if it matters, though we're planning on retesting
>> with it set to 1500.
>
> An MTU of 2000 bytes means a TCP segment with timestamps enabled will 
> be 2032 plus the ethernet header (assuming no vlan tags) of 14 bytes 
> for 2046 and then there is the trailing CRC - which is getting very 
> close to a magic power of two boundary, another place where history is 
> repleat with examples of bugs. One that comes to mind is that the old 
> Alteon AceNICs got very unhappy if one crossed a 4G boundary with a 
> DMA...

>
> rick jones
>
>>
>> I'm considering disabling the hardware CRC check as a
>> verification--looking at the niu driver I think I should be able to do
>> this by not including XMAC_CONFIG_RX_CRC_CHK_DIS in the big list of
>> flags being OR'd in niu_init_rx_xmac().
That is right.

Regards,
Matheos

>>
>> Anyone have any suggestions?
>>
>> Thanks,
>>
>> Chris
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html


      reply	other threads:[~2009-06-29 23:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-29 20:57 sun neptune mis-detecting ethernet crc faults? Chris Friesen
2009-06-29 21:29 ` Rick Jones
2009-06-29 23:13   ` Matheos Worku [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A494AB1.7010407@sun.com \
    --to=matheos.worku@sun.com \
    --cc=cfriesen@nortel.com \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).