Ben Hutchings <b...@decadent.org.uk> writes: > On Wed, 2020-05-20 at 13:09 +0000, Yannis Aribaud wrote: >> Package: ethtool >> Version: 1:4.19-1 >> Severity: important >> The command ethtool -m is unable to read the transceiver DOM values. > > Again, this is a driver or hardware issue, not a bug in ethtool. > > [...] >> As you can see all mesuring values are zeros. >> I am using Debian GNU/Linux 10 (buster), kernel 4.19.0-9-amd64 #1 SMP >> Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux and libc6 2.28-10 >> >> FYI, I get correct values using SystemRescueCD 6 (ethtool 5.0, kernel >> 4.19.34-1-lts) on this same hardware, using the same command. > > I see no changes to ethtool between 4.19 and 5.0 that would explain > that.
I assume you're aware of this, but there are some interesting changes in that driver between v4.19.34 and v4.19.118 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=7da11d6a5d85ab3f4d28fa660d8c90566fdaa1e6 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=935f39807a7e95678e5bda50757af326691a211c The net effect seems to be that they removed the part that actually made DOM reading work. Makes me wonder what happens if you revert both those patches? I don't have the hardware, so I can't test.. This issue might also be fixed in mainline with the more generic high page support for QSFP28 and QSFP+? Bjørn
