From: ѽ҉ᶬḳ℠ <vtol@gmx.net>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>, netdev@vger.kernel.org
Subject: Re: [drivers/net/phy/sfp] intermittent failure in state machine checks
Date: Thu, 9 Jan 2020 19:01:10 +0000 [thread overview]
Message-ID: <acd4d7e4-7f8e-d578-c9c9-b45f062f4fe2@gmx.net> (raw)
In-Reply-To: <20200109174322.GR25745@shell.armlinux.org.uk>
On 09/01/2020 17:43, Russell King - ARM Linux admin wrote:
> On Thu, Jan 09, 2020 at 05:35:23PM +0000, ѽ҉ᶬḳ℠ wrote:
>> Thank you for the extensive feedback and explanation.
>>
>> Pardon for having mixed up the semantics on module specifications vs. EEPROM
>> dump...
>>
>> The module (chipset) been designed by Metanoia, not sure who is the actual
>> manufacturer, and probably just been branded Allnet.
>> The designer provides some proprietary management software (called EBM) to
>> their wholesale buyers only
> I have one of their early MT-V5311 modules, but it has no accessible
> EEPROM, and even if it did, it would be of no use to me being
> unapproved for connection to the BT Openreach network. (BT SIN 498
> specifies non-standard power profile to avoid crosstalk issues with
> existing ADSL infrastructure, and I believe they regularly check the
> connected modem type and firmware versions against an approved list.)
>
> I haven't noticed the module I have asserting its TX_FAULT signal,
> but then its RJ45 has never been connected to anything.
>
The curious (and sort of inexplicable) thing is that the module in
general works, i.e. at some point it must pass the sm checks or
connectivity would be failing constantly and thus the module being
generally unusable.
The reported issues however are intermittent, usually reliably
reproducible with
ifdown <iface> && ifup <iface>
or rebooting the router that hosts the module.
If some times passes, not sure but seems in excess of 3 minutes, between
ifdown and ifup the sm checks mostly are not failing.
It somehow "feels" that the module is storing some link signal
information in a register which does not suit the sm check routine and
only when that register clears the sm check routine passes and
connectivity is restored.
____
Since there are probably other such SFP modules, xDSL and g.fast, out
there that do not provide laser safety circuitry by design (since not
providing connectivity over fibre) would it perhaps not make sense to
try checking for the existence of laser safety circuitry first prior
getting to the sm checks?
____
Sometime in the past sfp.c was not available in the distro and the issue
never exhibited. Back then the module's operations mode been set through
a py script - see bottom - but it would appear that it did not implement
any sm checks.
---py script
class SFP:
def __init__(self, i2cbus):
self.i2cbus = i2cbus
@staticmethod
def detect_metanoia_xdsl(eeprom):
return ['X', 'C', 'V', 'R', '-', '0', '8', '0', 'Y', '5',
'5',] == eeprom[40:51]
@staticmethod
def detect_zisa_gpon(eeprom):
return ['T', 'W', '2', '3', '6', '2', 'H'] == eeprom[40:47]
@staticmethod
def detect_sgmii(eeprom):
if ord(eeprom[6]) & 0x08:
d("Mode selected: generic SGMII")
return True
else:
d("Mode selected: generic 1000BASE-X")
return False
def decide_sfpmode(self):
ec = []
try:
ec = list(EEPROM(self.i2cbus).read_eeprom())
d("SFP EEPROM: %s" % str(ec))
except Exception as e:
l("EEPROM read error: " + str(e))
return 'phy-sfp'
# special case: Metanoia xDSL SFP, 1000BASE-X, no link
autonegotiation
if self.detect_metanoia_xdsl(ec):
l("Metanoia DSL SFP detected. Switching to phy-sfp-noneg
mode.")
return 'phy-sfp-noneg'
# special case: Zisa GPON SFP, SGMII
if self.detect_zisa_gpon(ec):
l("Zisa GPON SFP detected. Switching to phy-sfp-sgmii mode.")
return 'phy-sfp-sgmii'
# SGMII detection
if self.detect_sgmii(ec):
return 'phy-sfp-sgmii'
# default 1000BASE-X
return 'phy-sfp'
next prev parent reply other threads:[~2020-01-09 19:01 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 ` ѽ҉ᶬḳ℠ [this message]
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
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=acd4d7e4-7f8e-d578-c9c9-b45f062f4fe2@gmx.net \
--to=vtol@gmx.net \
--cc=andrew@lunn.ch \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
/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.