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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c7b4bec1-3f1f-8a34-cf22-8fb1f68914f3@gmx.net>
Date:   Thu, 9 Jan 2020 22:40:24 +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 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.