From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers Date: Wed, 26 Sep 2018 23:46:49 +0200 Message-ID: <20180926214649.GC1251@lunn.ch> References: <82CEAF9FFBA4DD428B132074FB91DF7D5F6481EA@CSI-MAILSRV.csicompanies.internal> <20180926194436.GB1251@lunn.ch> <82CEAF9FFBA4DD428B132074FB91DF7D5F64838C@CSI-MAILSRV.csicompanies.internal> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "linville@tuxdriver.com" , "netdev@vger.kernel.org" To: Chris Preimesberger Return-path: Received: from vps0.lunn.ch ([185.16.172.187]:46793 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726469AbeI0EB5 (ORCPT ); Thu, 27 Sep 2018 00:01:57 -0400 Content-Disposition: inline In-Reply-To: <82CEAF9FFBA4DD428B132074FB91DF7D5F64838C@CSI-MAILSRV.csicompanies.internal> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Sep 26, 2018 at 08:47:34PM +0000, Chris Preimesberger wrote: > Hello Andrew, >=20 > Thank you for the quick response!! > Apologies in advance for my use of outlook and top-posting, etc... >=20 > 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. >=20 > Pasted from Ubuntu CLI: >=20 > tech1@D7:~$=20 > tech1@D7:~$=20 > tech1@D7:~$=20 > tech1@D7:~$=20 > tech1@D7:~$ sudo ethtool -m enp1s0 raw on > =11UU$=EF=BF=BD=EF=BF=BDpA`?=EF=BF=BD@=EF=BF=BDG=10# > =EF=BF=BD=12v=01=11=EF=BF=BD=EF=BF=BD=03=EF=BF=BD=02@TRA= NSITION =EF=BF=BD=EF=BF=BDTNQSFP100GCWDM4 1AfX%=1CF?=06?=EF=BF=BDTN020= 00301 180919 =20 > h=EF=BF=BD=02I=EF=BF=BD=EF=BF=BD_=EF=BF=BD=EF=BF=BD'=16=EF=BF=BD=EF= =BF=BDRi=3D=02`=EF=BF=BD=EF=BF=BDZntech1@D7:~$=20 > tech1@D7:~$=20 > tech1@D7:~$=20 > tech1@D7:~$=20 > 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=20 > 0x0010: 00 00 00 00 00 00 24 e2 00 00 81 68 00 00 00 00=20 > 0x0020: 00 00 00 00 00 00 00 00 00 00 41 60 3f e0 40 e0=20 > 0x0030: 47 00 1f 10 0e 1e 0b f7 12 76 00 00 00 00 00 00=20 > 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00=20 > 0x0060: 00 00 00 00 00 00 00 00 00 00 1f 00 00 00 00 00=20 > 0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=20 > 0x0080: 11 fc 07 80 00 00 00 00 00 00 00 03 ff 00 02 00=20 > 0x0090: 00 00 00 40 54 52 41 4e 53 49 54 49 4f 4e 20 20=20 > 0x00a0: 20 20 20 20 00 00 c0 f2 54 4e 51 53 46 50 31 30=20 > 0x00b0: 30 47 43 57 44 4d 34 20 31 41 66 58 25 1c 46 3f=20 > 0x00c0: 06 00 3f d6 54 4e 30 32 30 30 30 33 30 31 20 20=20 > 0x00d0: 20 20 20 20 31 38 30 39 31 39 20 20 0c 00 68 f3=20 > 0x00e0: 00 00 02 49 80 a0 5f 1f de c9 27 16 f8 ae 52 69=20 > 0x00f0: 3d 02 60 00 00 00 00 00 00 00 00 00 83 f4 5a 6e=20 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