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 22:40:24 +0000 [thread overview]
Message-ID: <c7b4bec1-3f1f-8a34-cf22-8fb1f68914f3@gmx.net> (raw)
In-Reply-To: <20200109215903.GV25745@shell.armlinux.org.uk>
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.
next prev parent reply other threads:[~2020-01-09 22:40 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 ` ѽ҉ᶬḳ℠ [this message]
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=c7b4bec1-3f1f-8a34-cf22-8fb1f68914f3@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.