public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org>
To: Ivar Simensen <is@datarespons.no>
Cc: "mkubecek@suse.cz" <mkubecek@suse.cz>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: ethtool module info only reports hex info
Date: Thu, 23 Nov 2023 13:29:27 +0200	[thread overview]
Message-ID: <ZV83lz4bwSpeBFb0@shredder> (raw)
In-Reply-To: <AM0PR03MB5938EE1722EF2C75112B86F5B9B9A@AM0PR03MB5938.eurprd03.prod.outlook.com>

On Thu, Nov 23, 2023 at 07:42:07AM +0000, Ivar Simensen wrote:
> Hi
> I'm not sure if this is a conscious decision or a bug, but I discovered a change of behavior between version 5.4 an 5.16 according to get module info from a SFP Fiber connector: "ethtool -m ens5".
> 
> After upgrading a target from Ubuntu 18.04 to 22.04, I discovered that the ethtool just report a hex dump when I tried to verify my fiber SFP connectors. In 18.04 I got a report with ethtool. I have tried to upgrade from version 5.16 to 6.1 and 6.5, but it did not fix the issue. I then downgraded to version 5.4 and now it works again.
> 
> The expected result with "ethtool -m ens5" was to get a human readable report, and with "ethtool -m ens5 hex on" a hexdump.
> I have tried with the flag "hex on/off" on 5.16, but the result is always hex dump. 
> On version 5.4 this flag switches between hex dump and module info report as expected.

Can you try the following ethtool patch?

diff --git a/netlink/module-eeprom.c b/netlink/module-eeprom.c
index 49833a2a6a38..8b19f8e28c72 100644
--- a/netlink/module-eeprom.c
+++ b/netlink/module-eeprom.c
@@ -216,6 +216,8 @@ static int eeprom_parse(struct cmd_context *ctx)
 
        switch (request.data[0]) {
 #ifdef ETHTOOL_ENABLE_PRETTY_DUMP
+       case SFF8024_ID_GBIC:
+       case SFF8024_ID_SOLDERED_MODULE:
        case SFF8024_ID_SFP:
                return sff8079_show_all_nl(ctx);
        case SFF8024_ID_QSFP:

We might be missing more identifiers there. I can look into it next week
(around Wednesday).

If it doesn't work, you can try compiling ethtool without the new
netlink support and instead use the legacy ioctl interface:

$ ./configure --disable-netlink
$ make

Thanks

  reply	other threads:[~2023-11-23 11:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-23  7:42 ethtool module info only reports hex info Ivar Simensen
2023-11-23 11:29 ` Ido Schimmel [this message]
2023-11-24  9:33   ` Ivar Simensen
2023-11-23 15:19 ` Michal Kubecek
2023-11-24  7:38   ` Ivar Simensen
  -- strict thread matches above, loose matches on Subject: below --
2024-05-16  7:23 Frederic TOULBOT
2024-05-16 12:14 ` Andrew Lunn

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=ZV83lz4bwSpeBFb0@shredder \
    --to=idosch@idosch.org \
    --cc=is@datarespons.no \
    --cc=mkubecek@suse.cz \
    --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