On Thu, 2020-05-21 at 11:22 +0200, Bjørn Mork wrote: > 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
I actually hadn't looked yet, so thanks for doing that. > 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. Yes, these patches don't make sense. If only the real EEPROM is readable then the correct fix would be to change both type and size to the SFF-8079 values. > 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+? I don't know, I no longer keep track of networking stuff beyond what I read in LWN. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction.
signature.asc
Description: This is a digitally signed message part
