netdev - RE: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers

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: <82CEAF9FFBA4DD428B132074FB91DF7D5F648BA5@CSI-MAILSRV.csicompanies.internal>
Date:   Thu, 27 Sep 2018 18:56:46 +0000
From:   Chris Preimesberger <chrisp@...nsition.com>
To:     'Andrew Lunn' <andrew@...n.ch>,
        Eran Ben Elisha <eranbe@...lanox.com>
CC:     Neil Horman <nhorman@...driver.com>,
        "linville@...driver.com" <linville@...driver.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: bug: 'ethtool -m' reports spurious alarm & warning threshold
 values for QSFP28 transceivers

I greatly appreciate everyone's work on this.  Thank you to all.

I've had Mellanox support case # 00508027 open for this issue,
and just now requested an updated driver from them to resolve,
explaining that really smart ethtool developers figured out this
was due to the Mellanox driver not reporting thresholds to ethtool.

I intend to post back here for posterity if/when I get an updated
driver that fixes the issue.

Thanks again!!

Chris Preimesberger | Test & Validation Engineer
Transition Networks, Inc.

chrisp@...nsition.com
direct: +1.952.996.1509 | fax: +1.952.941.2322 | www.transition.com

-----Original Message-----
From: Andrew Lunn [mailto:andrew@...n.ch] 
Sent: Thursday, September 27, 2018 11:38 AM
To: Chris Preimesberger
Cc: Eran Ben Elisha; Neil Horman; linville@...driver.com; netdev@...r.kernel.org
Subject: Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers

On Thu, Sep 27, 2018 at 04:08:24PM +0000, Chris Preimesberger wrote:
> Please correct me if I'm wrong, but...
> It looks like Eran's proposed fix would remove all warning and alarm 
> indications from ethtool's output. It's worth mentioning that for me, 
> the following fields always reported correctly as Off while no alarm 
> condition was present and On while alarm condition(s) were present 
> *per the QSFP's true/programmed threshold values* *not per the 
> incorrectly reported threshold values*

These alarm values are in the first page. So the information the driver returns does contain this information. What is missing is the thresholds, which are not provided by the driver.

But there is a comment in the code:

        /*
         * There is no clear identifier to signify the existence of
         * optical diagnostics similar to SFF-8472. So checking existence
         * of page 3, will provide the gurantee for existence of alarms
         * and thresholds
         * If pagging support exists, then supports_alarms is marked as 1
         */

These alarm values are optional. The spec says so. So in order to decide if they are implemented, ethtool looks to see if the thresholds are available. If there are thresholds, it makes sense the alarms are implemented.

Unfortunately, the driver never returns the thresholds. So ethtool has no real choice and won't display the alarms since it cannot determine if they are valid.

In order to get alarms, the driver needs to be extended to return all the pages.

    Andrew