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 for Android: free password hash cracker in your pocket

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

Message-ID: <b4b94498-5011-1e89-db54-04916f8ef846@gmx.net>
Date:   Fri, 10 Jan 2020 15:02:51 +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 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

Kept an eye on the link state of the NIC (eth2) as well with - ip mo l 
dev eth2 - and it does not come up either with those transmit faults and 
only gets back online once the transmit faults are cleared.

At loss really, since it seems the SFP is not exhibiting any mischievous 
behaviour. It does not even reproduce reliably, just now it took a 
couple of attempts to invoke the transmit fault and other times it does 
straight away.
Suppose there could be always a hardware defect though it seems somewhat 
unlikely. That said, I do not have another such module available to swap 
for testing.