All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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.