On Wed, Sep 26, 2018 at 11:58:12PM +0200, Andrew Lunn wrote: > > 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. > No, not at all. Each driver that implements a get_eeprom ethtool method, is capable of doing multiple reads at various offsets, and filling up the user buffer with real data. The bug here is that the mellanox data structures are not sized properly vis a vis the amount of eeprom data that user space might expect, or more specifically that the driver isn't smart enough to do several small reads to fill up the full sized request buffer
Neil > Oh dear. > > Andrew >
