On Mon, Sep 13, 2021 at 10:59:05PM +0200, Heiner Kallweit wrote: > 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. It's possible we need to validate more. But that's not the solution to the current problem. > 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 do. If we don't *need* it during boot, there's no reason to read it then. It only slows down boot. Bjorn
