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]

Message-ID: <20200110150955.GE25745@shell.armlinux.org.uk>
Date:   Fri, 10 Jan 2020 15:09:55 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     ѽ҉ᶬḳ℠ <vtol@....net>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: [drivers/net/phy/sfp] intermittent failure in state machine
 checks

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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up