On 13.09.2021 22:32, Dave Jones wrote: > On Mon, Sep 13, 2021 at 10:22:57PM +0200, Heiner Kallweit wrote: > > > > This didn't help I'm afraid :( > > > It changed the VPD warning, but that's about it... > > > > > > [ 184.235496] pci 0000:02:00.0: calling quirk_blacklist_vpd+0x0/0x22 @ 1 > > > [ 184.235499] pci 0000:02:00.0: [Firmware Bug]: disabling VPD access (can't determine size of non-standard VPD format) > > > [ 184.235501] pci 0000:02:00.0: quirk_blacklist_vpd+0x0/0x22 took 0 usecs > > > > > With this patch there's no VPD access to this device any longer. So this can't be > > the root cause. Do you have any other PCI device that has VPD capability? > > -> Capabilities: [...] Vital Product Data > > > 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. > The stall being discussed would have been prevented by the VPD tag verification in pci_vpd_size(). It seems that now random data is interpreted as VPD tags what results in VPD access to an address that makes the device stall. I do not really follow Linus' argumentation that VPD shouldn't be accessed during boot because other slow "VPD-like" devices are accessed too, e.g. DDR SPD via I2C. > > I'll add that to the quirk list and see if that helps. > > Dave >
