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: Fri, 10 Jan 2020 15:45:15 +0000 [thread overview]
Message-ID: <e9a99276-c09d-fa8d-a280-fca2abac6602@gmx.net> (raw)
In-Reply-To: <20200110150955.GE25745@shell.armlinux.org.uk>
On 10/01/2020 15:09, Russell King - ARM Linux admin wrote:
> On Fri, Jan 10, 2020 at 03:02:51PM +0000, ѽ҉ᶬḳ℠ wrote:
>> On 10/01/2020 12:53, Russell King - ARM Linux admin wrote:
>>>>> Which is also indicating everything is correct. When the problem
>>>>> occurs, check the state of the signals again as close as possible
>>>>> to the event - it depends how long the transceiver keeps it
>>>>> asserted. You will probably find tx-fault is indicating
>>>>> "in hi IRQ".
>>>> just discovered userland - gpioinfo pca9538 - which seems more verbose
>>>>
>>>> gpiochip2 - 8 lines:
>>>> line 0: unnamed "tx-fault" input active-high [used]
>>>> line 1: unnamed "tx-disable" output active-high [used]
>>>> line 2: unnamed "rate-select0" input active-high [used]
>>>> line 3: unnamed "los" input active-high [used]
>>>> line 4: unnamed "mod-def0" input active-low [used]
>>>> line 5: unnamed unused input active-high
>>>> line 6: unnamed unused input active-high
>>>> line 7: unnamed unused input active-high
>>>>
>>>> The above is depicting the current state with the module working,
>>>> i.e. being
>>>> online. Will do some testing and report back, not sure yet how to
>>>> keep a
>>>> close watch relating to the failure events.
>>> However, that doesn't give the current levels of the inputs, so it's
>>> useless for the purpose I've asked for.
>> Fair enough. Operational (online) state
>>
>> gpiochip2: GPIOs 504-511, parent: i2c/8-0071, pca9538, can sleep:
>> gpio-504 ( |tx-fault ) in lo IRQ
>> gpio-505 ( |tx-disable ) out lo
>> gpio-506 ( |rate-select0 ) in lo
>> gpio-507 ( |los ) in lo IRQ
>> gpio-508 ( |mod-def0 ) in lo IRQ
>>
>> And the same remained (unchanged) during/after the events (as closely
>> I was
>> able to monitor) -> module transmit fault indicated
> Try:
>
> while ! grep -A4 'tx-fault.*in hi' /sys/kernel/debug/gpio; do :; done
>
> which may have a better chance of catching it.
>
Suppose you are not interested in what happens with ifdown wan, so just
for posterity
gpio-504 ( |tx-fault ) in hi IRQ
gpio-505 ( |tx-disable ) out hi
gpio-506 ( |rate-select0 ) in lo
gpio-507 ( |los ) in lo IRQ
gpio-508 ( |mod-def0 ) in lo IRQ
When the iif is brought up again and happens to trigger a transmit fault
the hi is not being triggered however. And it did not try 5 times to
recover from the fault, unless dmesg missed some
[Fri Jan 10 15:30:57 2020] mvneta f1034000.ethernet eth2: Link is Down
[Fri Jan 10 15:30:57 2020] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not
ready
[Fri Jan 10 15:31:13 2020] mvneta f1034000.ethernet eth2: configuring
for inband/1000base-x link mode
[Fri Jan 10 15:31:13 2020] sfp sfp: module transmit fault indicated
[Fri Jan 10 15:31:15 2020] mvneta f1034000.ethernet eth2: Link is Up -
1Gbps/Full - flow control off
[Fri Jan 10 15:31:16 2020] sfp sfp: module transmit fault recovered
[Fri Jan 10 15:31:16 2020] mvneta f1034000.ethernet eth2: Link is Down
[Fri Jan 10 15:31:16 2020] sfp sfp: module transmit fault indicated
[Fri Jan 10 15:31:19 2020] sfp sfp: module persistently indicates fault,
disabling
[Fri Jan 10 15:31:21 2020] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not
ready
[Fri Jan 10 15:31:21 2020] mvneta f1034000.ethernet eth2: configuring
for inband/1000base-x link mode
[Fri Jan 10 15:31:21 2020] sfp sfp: module transmit fault indicated
[Fri Jan 10 15:31:27 2020] sfp sfp: module persistently indicates fault,
disabling
[Fri Jan 10 15:38:01 2020] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not
ready
[Fri Jan 10 15:38:01 2020] mvneta f1034000.ethernet eth2: configuring
for inband/1000base-x link mode
[Fri Jan 10 15:38:01 2020] sfp sfp: module transmit fault indicated
[Fri Jan 10 15:38:07 2020] sfp sfp: module persistently indicates fault,
disabling
[Fri Jan 10 15:40:48 2020] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not
ready
[Fri Jan 10 15:40:48 2020] mvneta f1034000.ethernet eth2: configuring
for inband/1000base-x link mode
[Fri Jan 10 15:40:48 2020] sfp sfp: module transmit fault indicated
[Fri Jan 10 15:40:54 2020] sfp sfp: module persistently indicates fault,
disabling
Had to reboot the node to regain WAN connectivity.
next prev parent reply other threads:[~2020-01-10 15:45 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 ` ѽ҉ᶬḳ℠
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 ` ѽ҉ᶬḳ℠ [this message]
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=e9a99276-c09d-fa8d-a280-fca2abac6602@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.