netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Chris Preimesberger <chrisp@transition.com>
Cc: "linville@tuxdriver.com" <linville@tuxdriver.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
Date: Wed, 26 Sep 2018 23:46:49 +0200	[thread overview]
Message-ID: <20180926214649.GC1251@lunn.ch> (raw)
In-Reply-To: <82CEAF9FFBA4DD428B132074FB91DF7D5F64838C@CSI-MAILSRV.csicompanies.internal>

On Wed, Sep 26, 2018 at 08:47:34PM +0000, Chris Preimesberger wrote:
> Hello Andrew,
> 
> Thank you for the quick response!!
> Apologies in advance for my use of outlook and top-posting, etc...
> 
> I've run the raw option and the hex option, and pasted the results below.
> Since the raw option printed strange characters on the CLI, I re-ran it,
> Sending the output to a file (raw.txt) and attached that file as well.
> 
> Pasted from Ubuntu CLI:
> 
> tech1@D7:~$ 
> tech1@D7:~$ 
> tech1@D7:~$ 
> tech1@D7:~$ 
> tech1@D7:~$ sudo ethtool -m enp1s0 raw on
> \x11UU$��pA`?�@�G\x10#
>                  �\x12v\x01\x11��\x03�\x02@TRANSITION      ��TNQSFP100GCWDM4 1AfX%\x1cF?\x06?�TN02000301      180919  
>     h�\x02I��_��'\x16��Ri=\x02`��Zntech1@D7:~$ 
> tech1@D7:~$ 
> tech1@D7:~$ 
> tech1@D7:~$ 
> tech1@D7:~$ sudo ethtool -m enp1s0 hex on
> Offset		Values
> ------		------
> 0x0000:		11 00 00 0f 00 00 00 00 00 55 55 00 00 00 00 00 
> 0x0010:		00 00 00 00 00 00 24 e2 00 00 81 68 00 00 00 00 
> 0x0020:		00 00 00 00 00 00 00 00 00 00 41 60 3f e0 40 e0 
> 0x0030:		47 00 1f 10 0e 1e 0b f7 12 76 00 00 00 00 00 00 
> 0x0040:		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 0x0050:		00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 
> 0x0060:		00 00 00 00 00 00 00 00 00 00 1f 00 00 00 00 00 
> 0x0070:		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 0x0080:		11 fc 07 80 00 00 00 00 00 00 00 03 ff 00 02 00 
> 0x0090:		00 00 00 40 54 52 41 4e 53 49 54 49 4f 4e 20 20 
> 0x00a0:		20 20 20 20 00 00 c0 f2 54 4e 51 53 46 50 31 30 
> 0x00b0:		30 47 43 57 44 4d 34 20 31 41 66 58 25 1c 46 3f 
> 0x00c0:		06 00 3f d6 54 4e 30 32 30 30 30 33 30 31 20 20 
> 0x00d0:		20 20 20 20 31 38 30 39 31 39 20 20 0c 00 68 f3 
> 0x00e0:		00 00 02 49 80 a0 5f 1f de c9 27 16 f8 ae 52 69 
> 0x00f0:		3d 02 60 00 00 00 00 00 00 00 00 00 83 f4 5a 6e 

Hi Chris

I've only recently got involved with SFP modules. ethtool says this is
a SFF-8636 SFP. So a QSFP. It has multiple pages, each 128 bytes in
length, which should be returned in a concatenated form. Here we see
256 bytes, meaning there are two pages. There can be up to 5 pages.

ethtool is looking for the temperature alarms at offset 0x200. So that
does not exist in this hex dump. But the raw dump you provided has
more bytes, 0x400 of them.

So i would say the first bug is that ethtool dumps different amounts
of data in hex than raw.

The fact you get different alarm thresholds on different runs suggests
to me we might only be getting two pages from the kernel?

Can you build ethtool from source and run it inside a debugger?
ethtool makes two IOCTL calls. The first is ETHTOOL_GMODULEINFO.
Could you print out the modinfo which is returned. It then does a
ETHTOOL_GMODULEEEPROM. Can you print out eeprom after the second
IOCTL.

Thanks
	Andrew

  reply	other threads:[~2018-09-27  4:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-26 19:29 bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers Chris Preimesberger
2018-09-26 19:44 ` Andrew Lunn
2018-09-26 20:47   ` Chris Preimesberger
2018-09-26 21:46     ` Andrew Lunn [this message]
2018-09-26 21:34 ` Neil Horman
2018-09-26 21:58   ` Andrew Lunn
2018-09-27 13:23     ` Neil Horman
2018-09-27 13:25   ` Eran Ben Elisha
2018-09-27 14:52     ` Andrew Lunn
2018-09-27 15:20       ` Eran Ben Elisha
2018-09-27 15:32         ` Andrew Lunn
2018-09-27 16:08           ` Chris Preimesberger
2018-09-27 16:38             ` Andrew Lunn
2018-09-27 18:56               ` Chris Preimesberger
2018-09-27 20:17                 ` Chris Preimesberger
2018-10-02  7:10           ` Eran Ben Elisha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180926214649.GC1251@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=chrisp@transition.com \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).