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 20:27:39 +0000 [thread overview]
Message-ID: <b8b9a61c-d361-e6dd-1cd9-db4cea624fd7@gmx.net> (raw)
In-Reply-To: <20200110195533.GM25745@shell.armlinux.org.uk>
On 10/01/2020 19:55, Russell King - ARM Linux admin wrote:
>
> Define "stable once the interface is up". Is that stable after ten
> seconds? Or stable in under the 300ms initialisation delay allowed
> by the SFP MSA?
The router boots, SFP.C is called and performs its functions and the
module gets online and stays that way.
At some point the modules thus apparently passes the checks, incl. the
under the 300ms initialisation, or else it would never get online and I
could trash it.
Once up it is rock-solid - the IRQ values are staying constant.
If at later stage the iif is being brought down and up again the issue
starts to exhibit.
>
>> The 5 toggles are resulting from manually invoking ifupdown action.
>>
>>> Therefore, I'd say that the SFP state machines are operating as
>>> designed, and as per the SFP MSA, and what we have is a module that
>>> likes to assert TX_FAULT for unknown reasons, and this confirms the
>>> hypothesis I've been putting forward.
>>>
>> This is based on the 5 IRQ toggles or the previous reading on the GPIO
>> output?
> On _both_.
>
>
> Okay, I give up trying to help you. Sorry, but I've spent a lot of
> time over the last two days trying to help and explain stuff, and
> you seem to want to constantly tell me I'm wrong, or misreading what
> you're saying, or that there's some problem with the "sm check"
> when I've already pointed out is a figment of your imagination.
Not sure really why took such offence from that bit of summary.
I am not saying/implying that you are wrong, just beg to differ - there
is no explanation why the module is passing the test on initial up (at
boot time) but failing intermittently with ifupdown action later on,
that is all I am saying.
That the module is failing checks is hardly a figment of my imagination
or else I would not have bothered in seeking support in various places,
and prior reaching out all the way upstream having tried first in this
order:
- TOS
- OpenWrt
- vendor
> Sorry, but I'm not prepared to help any further.
It would be just sad to leave on such note and thus just let me
emphasize that I have thoroughly enjoyed and appreciated the exchange.
Unless you object me posting to this mailing list I would just remove
your email address then.
next prev parent reply other threads:[~2020-01-10 20:27 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 ` ѽ҉ᶬḳ℠
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 ` ѽ҉ᶬḳ℠ [this message]
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=b8b9a61c-d361-e6dd-1cd9-db4cea624fd7@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.