From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiner Kallweit Date: Wed, 15 Sep 2021 18:05:34 +0200 Subject: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue In-Reply-To: <14f6d9e9-aca8-133-67f5-92effa2ea280@twofifty.com> References: <20210913141818.GA27911@codemonkey.org.uk> <20210913201519.GA15726@codemonkey.org.uk> <20210913203234.GA6762@codemonkey.org.uk> <367cc748-d411-8cf8-ff95-07715c55e899@gmail.com> <20210914142419.GA32324@codemonkey.org.uk> <80718d5e-a4d2-ff85-aa8f-cd790c951278@gmail.com> <14f6d9e9-aca8-133-67f5-92effa2ea280@twofifty.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On 15.09.2021 16:18, Hisashi T Fujinaka wrote: > On Tue, 14 Sep 2021, Heiner Kallweit wrote: > >> On 14.09.2021 22:00, Hisashi T Fujinaka wrote: >>> On Tue, 14 Sep 2021, Dave Jones wrote: >>> >>>> On Tue, Sep 14, 2021 at 07:51:22AM +0200, Heiner Kallweit wrote: >>>> >>>>>> Sorry to reply from my personal account. If I did it from my work >>>>>> account I'd be top-posting because of Outlook and that goes over like a >>>>>> lead balloon. >>>>>> >>>>>> Anyway, can you send us a dump of your eeprom using ethtool -e? You can >>>>>> either send it via a bug on e1000.sourceforge.net or try sending it to >>>>>> todd.fujinaka at intel.com >>>>>> >>>>>> The other thing is I'm wondering is what the subvendor device ID you >>>>>> have is referring to because it's not in the pci database. Some ODMs >>>>>> like getting creative with what they put in the NVM. >>>>>> >>>>>> Todd Fujinaka (todd.fujinaka at intel.com) >>>>> >>>>> Thanks for the prompt reply. Dave, could you please provide the requested >>>>> information? >>>> >>>> sent off-list. >>>> >>>> ??? Dave >>> >>> Whoops. I replied from outlook again. >>> >>> I have confirmation that this should be a valid image. The VPD is just a >>> series of 3's. There are changes to preboot header, flash and BAR size, >>> and as far as I can tell, a nonsense subdevice ID, but this should work. >>> >>> What was the original question? >>> >> "lspci -vv" complains about an invalid short tag 0x06 and the PCI VPD >> code resulted in a stall. So it seems the data doesn't have valid VPD >> format as defined in PCI specification. >> >> 01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) >> ?????? Subsystem: Device 1dcf:030a >> ????... >> ??????????? Capabilities: [e0] Vital Product Data >> ?????????????? *Unknown small resource type 06, will not decode more.* >> >> Not sure which method is used by the driver to get the EEPROM content. >> For the issue here is relevant what is exposed via PCI VPD. >> >> The related kernel error message has been reported few times, e.g. here: >> https://access.redhat.com/solutions/3001451 >> Only due to a change in kernel code this became a more prominent >> issue now. >> >> You say that VPD is just a series of 3's. This may explain why kernel and >> tools complain about an invalid VPD format. VPD misses the tag structure. > > I think I conflated two issues and yours may not be the one with the > weird Amazon NIC. In any case, the VPD does not match the spec and two > people have confirmed it's just full of 3's. With the bogus subvendor > ID, I'm thinking this is not an Intel NIC. > > Next step is to contact whoever made the NIC and ask them for guidance. > In an earlier mail in this thread was stated that subvendor id is unknown. Checking here https://pcisig.com/membership/member-companies?combine=1dcf it says: Beijing Sinead Technology Co., Ltd. > Todd Fujinaka