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] [day] [month] [year] [list]

Message-ID: <53634c00-0fdc-a084-10b2-bfe64dd5181a@gmx.net>
Date:   Sat, 11 Jan 2020 12:58:29 +0000
From:   ѽ҉ᶬḳ℠ <vtol@....net>
To:     netdev@...r.kernel.org
Cc:     Andrew Lunn <andrew@...n.ch>
Subject: Re: [drivers/net/phy/sfp] intermittent failure in state machine
 checks

On 10/01/2020 19:23, Andrew Lunn wrote:
>> If really necessary I could ask the TOS developers to assist, not sure
>> whether they would oblidge. Their Master branch build bot compiles twice a
>> day.
>> Would it just involve setting a kernel debug flag or something more
>> elaborate?
> You could ask them to build a kernel with dynamic debug enabled
>
> https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html
>
> You can then turn on debugging in a flexible way. And it will be
> useful for more than just you.
>
>      Andrew

I have put in the request and will see how it goes, if positive I would
probably need a bit of guidance of how to leverage it.

Meantime, assuming for a moment that:

- the issue is not caused by SFP.C (emphasising that I reckon it is
indeed not)
- the is not caused by the module either (which I am not certain of)

, and considering that /sys/kernel/debug/gpio is not mounted on a block
device,

I was wondering whether the I2C bus could potentially get chocked of
sorts and thus preventing the module to propagate the change in tx-fault
signal state in a timely fashion (300 ms) to the kernel, thus being the
actual culprit?