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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 10 Jan 2020 20:27:39 +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 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.