linux-kernel - Re: [RFC PATCH net-next 05/10] Documentation: networking: ethtool-netlink: Add link extended state

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:   Mon, 8 Jun 2020 18:59:17 +0300
From:   Amit Cohen <amitc@...lanox.com>
To:     Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, kuba@...nel.org, corbet@....net,
        jiri@...lanox.com, idosch@...lanox.com, shuah@...nel.org,
        mkubecek@...e.cz, gustavo@...eddedor.com,
        cforno12@...ux.vnet.ibm.com, andrew@...n.ch,
        linux@...pel-privat.de, alexandru.ardelean@...log.com,
        ayal@...lanox.com, petrm@...lanox.com, mlxsw@...lanox.com,
        liuhangbin@...il.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [RFC PATCH net-next 05/10] Documentation: networking:
 ethtool-netlink: Add link extended state

On 07-Jun-20 22:11, Florian Fainelli wrote:
> 
> 
> On 6/7/2020 7:59 AM, Amit Cohen wrote:
>> Add link extended state attributes.
>>
>> Signed-off-by: Amit Cohen <amitc@...lanox.com>
>> Reviewed-by: Petr Machata <petrm@...lanox.com>
>> Reviewed-by: Jiri Pirko <jiri@...lanox.com>
> 
> If you need to resubmit, I would swap the order of patches #4 and #5
> such that the documentation comes first.
> 
> [snip]

ok

> 
>>  
>> +Link extended states:
>> +
>> +  ============================    =============================================
>> +  ``Autoneg failure``             Failure during auto negotiation mechanism
>> +
>> +  ``Link training failure``       Failure during link training
>> +
>> +  ``Link logical mismatch``       Logical mismatch in physical coding sublayer
>> +                                  or forward error correction sublayer
>> +
>> +  ``Bad signal integrity``        Signal integrity issues
>> +
>> +  ``No cable``                    No cable connected
>> +
>> +  ``Cable issue``                 Failure is related to cable,
>> +                                  e.g., unsupported cable
>> +
>> +  ``EEPROM issue``                Failure is related to EEPROM, e.g., failure
>> +                                  during reading or parsing the data
>> +
>> +  ``Calibration failure``         Failure during calibration algorithm
>> +
>> +  ``Power budget exceeded``       The hardware is not able to provide the
>> +                                  power required from cable or module
>> +
>> +  ``Overheat``                    The module is overheated
>> +  ============================    =============================================
>> +
>> +Many of the substates are obvious, or terms that someone working in the
>> +particular area will be familiar with. The following table summarizes some
>> +that are not:
> 
> Not sure this comment is helping that much, how about documenting each
> of the sub-states currently defined, even if this is just paraphrasing
> their own name? Being able to quickly go to the documentation rather
> than looking at the header is appreciable.
> 
> Thank you!

np, I'll add.
> 
>> +
>> +Link extended substates:
>> +
>> +  ============================    =============================================
>> +  ``Unsupported rate``            The system attempted to operate the cable at
>> +                                  a rate that is not formally supported, which
>> +                                  led to signal integrity issues
> 
> Do you have examples? Would you consider a 4-pair copper cable for
> Gigabit that has a damaged pair and would downshift somehow fall in that
> category?
> 

For example, this statement might appear when an 100G OPTICs (not copper) which is used in 40G rate and sees high BER (when using Parallel Detect).
In this situation we recommend to  see the other end configuration and understand why it is configured to lower speed.

Regarding your example, if it stays on the same speed and have high BER you should expect a different BAD SI statement.