From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: ѽ҉ᶬḳ℠ <vtol@gmx.net>
Cc: Andrew Lunn <andrew@lunn.ch>, netdev@vger.kernel.org
Subject: Re: [drivers/net/phy/sfp] intermittent failure in state machine checks
Date: Fri, 10 Jan 2020 10:26:07 +0000 [thread overview]
Message-ID: <20200110102607.GY25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <d10c8598-a3d2-3936-8713-0763b156938c@gmx.net>
On Fri, Jan 10, 2020 at 12:18:41AM +0000, ѽ҉ᶬḳ℠ wrote:
> On 09/01/2020 23:50, ѽ҉ᶬḳ℠ wrote:
> > Maybe I should just try finding a module that is declared SPF MSA
> > conform...
>
> Actually, the vendors declares
> (https://www.allnet.de/en/allnet-brand/produkte/neuheiten/p/-0c35cc9ea9/):
>
> *ALLNET ALL4781-VDSL2-SFP* is a VDSL2 SFP modem that interconnects with
> Gateway Processor by using a MSA (MultiSource Agreement) compliant hot
> pluggable electrical interface.
>
> Ok, "a MSA" does not explicitly state/imply SFP MSA but what other MSA could
> that be?
> If it is indeed SFP MSA conform the issue should not happen. Unless it is
> just marketing speak and does not hold true.
Everyone claims that their SFP is MSA compliant, even when the module:
1) takes 40-50 seconds after deasserting TX_DISABLE to initialise and
deassert TX_FAULT, when the SFP MSA explicitly states a limit of
300ms (t_init) for TX_FAULT to deassert.
2) EEPROM does not respond for 50 seconds after plugging in, where the
SFP MSA explicitly states 300ms (t_serial) maximum.
3) EEPROM contains incorrect data, for example:
- indicating the module has a LC connector, yet it has an RJ45, or
vice versa.
- indicating NRZ encoding for an ethernet SFP, where it should be
8b10b or 64b66b encoding.
- indicating a single data rate, or even the wrong data rate, when
the module is documented as supporting other rates.
- indicating an extended compliance technology that it doesn't
support, presumably originally chosen when the number was
unallocated by SFF-8024.
- claiming to support 1000BASE-SX, a fiber standard, when the
module is actually for VDSL2 over copper.
... etc ...
So, I tend to ignore "SFP MSA compliant" whenever I see it; it is
mostly meaningless. Yes, there are modules out there which are
compliant, but those that claim compliance but aren't make the
claim meaningless for everyone.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
next prev parent reply other threads:[~2020-01-10 10:26 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-09 13:47 [drivers/net/phy/sfp] intermittent failure in state machine checks ѽ҉ᶬḳ℠
2020-01-09 14:41 ` Andrew Lunn
2020-01-09 15:03 ` ѽ҉ᶬḳ℠
2020-01-09 15:58 ` Russell King - ARM Linux admin
2020-01-09 17:35 ` ѽ҉ᶬḳ℠
2020-01-09 17:43 ` Russell King - ARM Linux admin
2020-01-09 19:01 ` ѽ҉ᶬḳ℠
2020-01-09 19:42 ` ѽ҉ᶬḳ℠
2020-01-09 21:38 ` Russell King - ARM Linux admin
2020-01-09 21:59 ` Russell King - ARM Linux admin
2020-01-09 22:40 ` ѽ҉ᶬḳ℠
2020-01-09 23:10 ` Russell King - ARM Linux admin
2020-01-09 23:50 ` ѽ҉ᶬḳ℠
2020-01-10 0:18 ` ѽ҉ᶬḳ℠
2020-01-10 10:26 ` Russell King - ARM Linux admin [this message]
2020-01-10 9:27 ` Russell King - ARM Linux admin
2020-01-10 9:50 ` ѽ҉ᶬḳ℠
2020-01-10 10:19 ` ѽ҉ᶬḳ℠
2020-01-10 11:46 ` Russell King - ARM Linux admin
2020-01-10 13:22 ` Andrew Lunn
2020-01-10 13:38 ` ѽ҉ᶬḳ℠
2020-01-10 11:44 ` Russell King - ARM Linux admin
2020-01-10 12:45 ` ѽ҉ᶬḳ℠
2020-01-10 12:53 ` Russell King - ARM Linux admin
2020-01-10 15:02 ` ѽ҉ᶬḳ℠
2020-01-10 15:09 ` Russell King - ARM Linux admin
2020-01-10 15:45 ` ѽ҉ᶬḳ℠
2020-01-10 16:32 ` Russell King - ARM Linux admin
2020-01-10 16:53 ` ѽ҉ᶬḳ℠
2020-01-10 17:08 ` Russell King - ARM Linux admin
2020-01-10 17:19 ` ѽ҉ᶬḳ℠
2020-01-10 17:38 ` Russell King - ARM Linux admin
2020-01-10 18:44 ` ѽ҉ᶬḳ℠
2020-01-10 19:01 ` Russell King - ARM Linux admin
2020-01-10 19:36 ` ѽ҉ᶬḳ℠
2020-01-10 19:55 ` Russell King - ARM Linux admin
2020-01-10 20:27 ` ѽ҉ᶬḳ℠
2020-01-10 19:23 ` Andrew Lunn
2020-01-11 12:58 ` ѽ҉ᶬḳ℠
2020-01-09 21:34 ` Russell King - ARM Linux admin
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=20200110102607.GY25745@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=netdev@vger.kernel.org \
--cc=vtol@gmx.net \
/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).