Thread (40 messages) 40 messages, 3 authors, 2020-01-11

Re: [drivers/net/phy/sfp] intermittent failure in state machine checks

From: ѽ҉ᶬḳ℠ <hidden>
Date: 2020-01-09 22:40:32

On 09/01/2020 21:59, Russell King - ARM Linux admin wrote:
Also, note that the Metanoia MT-V5311 (at least mine) uses 1000BASE-X
not SGMII. It sends a 16-bit configuration word of 0x61a0, which is:

		1000BASE-X			SGMII
Bit 15	0	No next page			Link down
	1	Ack				Ack
	1	Remote fault 2			Reserved (0)
	0	Remote fault 1			Duplex (0 = Half)

	0	Reserved (0)			Speed bit 1
	0	Reserved (0)			Speed bit 0 (00=10Mbps)
	0	Reserved (0)			Reserved (0)
	1	Asymetric pause direction	Reserved (0)

	1	Pause				Reserved (0)
	0	Half duplex not supported	Reserved (0)
	1	Full duplex supported		Reserved (0)
	0	Reserved (0)			Reserved (0)

	0	Reserved (0)			Reserved (0)
	0	Reserved (0)			Reserved (0)
	0	Reserved (0)			Reserved (0)
Bit 0	0	Reserved (0)			Must be 1

So it clearly fits 802.3 Clause 37 1000BASE-X format, reporting 1G
Full duplex, and not SGMII (10M Half duplex).

I have a platform here that allows me to get at the raw config_reg
word that the other end has sent which allows analysis as per the
above.
The driver reports also 1000base-x for this Metonia/Allnet module:

mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode

mii-tool -v eth2 producing

eth2: 1000 Mbit, full duplex, link ok
   product info: vendor 00:00:00, model 0 rev 0
   basic mode:   10 Mbit, full duplex
   basic status: autonegotiation complete, link ok
   capabilities:
   advertising:  1000baseT-HD 1000baseT-FD 100baseT4 100baseTx-FD 
100baseTx-HD 10baseT-FD 10baseT-HD flow-control
______

On 09/01/2020 21:34, Russell King - ARM Linux admin wrote:
You can check the state of the GPIOs by looking at
/sys/kernel/debug/gpio, and you will probably see that TX_FAULT is
being asserted by the module.
With OpenWrt trying to save space wherever they can

# CONFIG_DEBUG_GPIO is not set

this avenue is unfortunately is not available. Is there some other way 
(Linux userland) to query TX_FAULT and RX_LOS and whether either/both 
being asserted or deasserted?
___

On 09/01/2020 21:34, Russell King - ARM Linux admin wrote:
BTW, I notice in you original kernel that you have at least one of my
"experimental" patches on your stable kernel taken from my "phy" branch
which has never been in mainline, so I guess you're using the OpenWRT
kernel?
I am not aware were the code originated from. It is not exactly OpenWrt 
but TOS (for the Turris Omnia router), being a downstream patchset that 
builds on top of OpenWrt. The TOS developers might be known at Linux 
kernel development, recently added their MOX platform and also with 
regard to Multi-CPU-DSA.
___

On 09/01/2020 21:34, Russell King - ARM Linux admin wrote:
You're reading/way/  too much into the state machine.
How so? Those intermittent failures cause disruption in the WAN 
connectivity - nothing life threatening but somewhat inconvenient.
I am trying to get to the bottom of it, with my limited capabilities and 
with your input it has helped. I will ping Allnet again and see whether 
they bother to respond and shed some light of what their modules does 
with regard to TX_FAULT and RX_LOS.


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help