[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <acd4d7e4-7f8e-d578-c9c9-b45f062f4fe2@gmx.net>
Date: Thu, 9 Jan 2020 19:01:10 +0000
From: ѽ҉ᶬḳ℠ <vtol@....net>
To: Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: [drivers/net/phy/sfp] intermittent failure in state machine
checks
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'
Powered by blists - more mailing lists