From: Richard Genoud <richard@sorico.fr>
To: Willy Tarreau <w@1wt.eu>, Richard Genoud <richard.genoud@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Antoine Tenart <antoine.tenart@bootlin.com>,
Gregory CLEMENT <gregory.clement@bootlin.com>,
Yelena Krivosheev <yelena@marvell.com>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>
Subject: Re: CRC errors between mvneta and macb
Date: Tue, 23 Oct 2018 08:56:07 +0200 [thread overview]
Message-ID: <b0ff037c-e32b-6f47-e108-5daefff9b42a@sorico.fr> (raw)
In-Reply-To: <20181022163429.GA22826@1wt.eu>
Le 22/10/2018 à 18:34, Willy Tarreau a écrit :
> On Mon, Oct 22, 2018 at 05:15:21PM +0200, Richard Genoud wrote:
>> After analyzing the ethernet frame on the Davicom PHY's output (pin
>> TX+), I find out that the FCS errors occurs when the ethernet preamble
>> is longer than 56bits. (something like 58 or 60 bits)
>>
>> To say this in another way, instead of having 28 times 1-0 followed by
>> the SFD (10101011), I see 29 or 30 times 1-0 followed by the SFD.
>> (sometimes 29, sometimes 30)
>>
>>
>> Should a longer preamble be considered as an FCS error ? It seems a
>> little harsh since the point of the preamble is to synchronize the frame.
>
> That indeed seems a bit strange considering that you're not supposed to
> know what is before the preamble so it would very well contain random
> noise looking a lot like alteranted bits.
>
>> I don't know what the 802.3 standard says about that.
>
> Just found it :-)
>
> https://www.trincoll.edu/Academics/MajorsAndMinors/Engineering/Documents/IEEE%20Standard%20for%20Ethernet.pdf
>
> Page 132, #7.2.3.2 :
>
> The DTE is required to supply at least 56 bits of preamble in
> order to satisfy system requirements. System components consume
> preamble bits in order to perform their functions. The number
> of preamble bits sourced ensures an adequate number of bits are
> provided to each system component to correctly implement its
> function.
>
> So that totally makes sense since the purpose is to enable signal
> detection at the hardware leve, hence the problem definitely is on
> the receiver in your case.
>
> Willy
>
Great ! Thanks !
I'll check on the Marvell side
Richard
next prev parent reply other threads:[~2018-10-23 7:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-19 15:15 Richard Genoud
2018-10-19 15:44 ` Willy Tarreau
2018-10-22 6:51 ` Richard Genoud
2018-10-22 15:15 ` Richard Genoud
2018-10-22 16:34 ` Willy Tarreau
2018-10-23 6:56 ` Richard Genoud [this message]
2018-10-22 18:19 ` Andrew Lunn
2018-10-23 6:58 ` Richard Genoud
2018-10-23 12:37 ` Richard Genoud
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=b0ff037c-e32b-6f47-e108-5daefff9b42a@sorico.fr \
--to=richard@sorico.fr \
--cc=andrew@lunn.ch \
--cc=antoine.tenart@bootlin.com \
--cc=gregory.clement@bootlin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=richard.genoud@gmail.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=w@1wt.eu \
--cc=yelena@marvell.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
all inboxes | Powered by JetHome®