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:58:12 +0200 Message-ID: <20180926215812.GD1251@lunn.ch> References: <82CEAF9FFBA4DD428B132074FB91DF7D5F6481EA@CSI-MAILSRV.csicompanies.internal> <20180926213436.GA4116@hmswarspite.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Chris Preimesberger , "linville@tuxdriver.com" , "netdev@vger.kernel.org" To: Neil Horman Return-path: Received: from vps0.lunn.ch ([185.16.172.187]:46804 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726098AbeI0ENW (ORCPT ); Thu, 27 Sep 2018 00:13:22 -0400 Content-Disposition: inline In-Reply-To: <20180926213436.GA4116@hmswarspite.think-freely.org> Sender: netdev-owner@vger.kernel.org List-ID: > When you run ethtool -m on this driver, the kernel calls mlx4_en_get_module_info > to determine the length of the eeprom, and that value will be either 256 or 512 > bytes. So it sounds like QSFP modules using 8636 are not supported. You would expect a size to be one of 256, 384, 512 or 640. > Next it calls mlx4_en_get_module_eeprom, passing in that size 256 to actually > read the eeprom data, which in turn calls mlx4_get_module_info to fetch the data > from hardware, again, passing in 256 as the size for the first call (theres a > loop, but it will only get executed once in this scenario) > > mlx4_get_module_info then issues the appropriate mailbox commands to dump the > eeprom. Here it starts to go sideways. The mailbox buffer allocated for the > return data is of type mlx4_mad_ifc, which has some front matter information and > a data buffer that is 192 bytes long! Which suggests all SFP dumps are broken as well, not just QSFP. Oh dear. Andrew