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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.