All of lore.kernel.org
 help / color / mirror / Atom feed
* Linux 5.15-rc1
@ 2021-09-12 23:58 Linus Torvalds
  2021-09-13  3:57 ` Guenter Roeck
  2021-09-13 14:18 ` Dave Jones
  0 siblings, 2 replies; 53+ messages in thread
From: Linus Torvalds @ 2021-09-12 23:58 UTC (permalink / raw)
  To: Linux Kernel Mailing List

So 5.15 isn't shaping up to be a particularly large release, at least
in number of commits. At only just over 10k non-merge commits, this is
in fact the smallest rc1 we have had in the 5.x series. We're usually
hovering in the 12-14k commit range.

That said, counting commits isn't necessarily the best measure, and
that might be particularly true this time around. We have a few new
subsystems, with NTFSv3 and ksmbd standing out. And as a result, when
you look at the stats on a "lines changed" basis, 5.15-rc1 ends up
looking much more middle-of-the-road. It still doesn't look like a
particularly _big_ merge window, but also not remotely the smallest
one.

And while this is not up there with some larger releases, it's
actually been one of the messier merge windows. Part of it was
self-inflicted damage from me trying to enable -Werror much more
aggressively, but I also ended up having to push back a lot more on
some of the patch series and had a number o full requests where I went
"ok, I've pulled this, but XYZ is wrong".

So we've had merge windows that went much more smoothly. In fact, I
have a pull request or two that I just didn't feel like going through
fully, and I might still pull the upcoming week, but I got a bit fed
up with how I ended up seeing new pull requests - and not for fixes -
coming in fairly late in the merge window. Yes, the merge window is
two weeks, but part of that is very literally to give _me_ time to
actually look things through, not for people to send me new requests
up until the very end of the merge window.

Anyway, I'm hoping that things calm down, and I'll take a look at a
few things still in my inbox, but on the whole you should expect that
"that's it" and send me fixes only.

And in order to get those fixes going, please go out and test this.

Appended, as always, is my "mergelog" - since even at "only" 10k+
commits, the shortlog is not really realistically readable or useful
as a summary. And as always, the mergelog credits the person I pulled
from, which is not the same as the actual author of all the changes.
There's just over a hundred people listed below that I've pulled from,
but over 1500 people with authorship credit in the git tree. So that's
where you'd need to dig for all the details.

Thanks,
            Linus

---

Al Viro (4):
    iov_iter fixes
    root filesystem type handling updates
    gfs2 setattr updates
    namei updates

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (1):
    RTC updates

Andreas Gruenbacher (1):
    gfs2 updates

Andrew Morton (3):
    misc updates
    more updates
    yet more updates and hotfixes

Anna Schumaker (1):
    NFS client updates

Arnaldo Carvalho de Melo (2):
    perf tool updates
    more perf tools updates

Arnd Bergmann (5):
    asm-generic updates
    ARM SoC updates
    ARM SoC driver updates
    ARM defconfig updates
    ARM SoC DT updates

Bartosz Golaszewski (1):
    gpio updates

Benson Leung (1):
    chrome platform updates

Bjorn Andersson (1):
    remoteproc updates

Bjorn Helgaas (1):
    PCI updates

Borislav Petkov (8):
    EDAC updates
    RAS update
    x86 build updates
    x86 resource control updates
    x86 cleanups
    timer fix
    locking fixes
    scheduler fixes

Casey Schaufler (1):
    smack updates

Catalin Marinas (2):
    arm64 updates
    arm64 fixes

Christian Brauner (4):
    move_mount updates
    close_range() cleanup
    idmapping documentation updates
    set_user()  update

Christoph Hellwig (2):
    configfs updates
    dma-mapping updates

Chuck Lever (2):
    nfsd updates
    nfsd fixes

Corey Minyard (1):
    IPMI updates

Dan Williams (2):
    libnvdimm updates
    CXL (Compute Express Link) updates

Daniel Lezcano (1):
    thermal updates

Daniel Thompson (1):
    kgdb updates

Darrick Wong (3):
    project quota update
    iomap updates
    xfs updates

Dave Airlie (2):
    drm updates
    drm fixes

David Hildenbrand (1):
    MAP_DENYWRITE removal

David Howells (1):
    fscache updates

David Sterba (2):
    btrfs updates
    btrfs fixes

David Teigland (1):
    dlm updates

Dmitry Torokhov (1):
    input updates

Dominique Martinet (1):
    9p updates

Eric Biederman (2):
    siginfo si_trapno updates
    exit cleanups

Eric Biggers (1):
    fscrypt updates

Gao Xiang (1):
    erofs updates

Geert Uytterhoeven (1):
    m68k updates

Greg KH (8):
    char / misc driver updates
    driver core updates
    IIO and staging driver updates
    tty / serial updates
    USB / Thunderbolt updates
    more USB updates
    habanalabs updates
    misc driver fix

Greg Ungerer (1):
    m68knommu updates

Guenter Roeck (1):
    hwmon updates

Hans de Goede (1):
    x86 platform driver updates

Heiko Carstens (2):
    s390 updates
    more s390 updates

Helge Deller (3):
    parisc architecture updates
    parisc architecture fixes
    parisc fixes

Herbert Xu (1):
    crypto updates

Ilya Dryomov (1):
    ceph updates

Ingo Molnar (4):
    scheduler updates
    x86 perf event updates
    EFI updates
    memory model updates

Jaegeuk Kim (1):
    f2fs updates

Jakub Kicinski (2):
    networking updates
    networking fixes and stragglers

James Bottomley (1):
    SCSI updates

Jan Kara (4):
    fsnotify updates
    FIEMAP cleanups
    UDF and isofs updates
    fs hole punching vs cache filling race fixes

Jarkko Sakkinen (1):
    tpm driver updates

Jason Gunthorpe (2):
    rdma updates
    rdma fixes

Jassi Brar (1):
    mailbox updates

Jean Delvare (1):
    dmi fix

Jeff Layton (1):
    file locking updates

Jens Axboe (13):
    block updates
    block driver updates
    libata updates
    io_uring updates
    support for struct bio recycling
    io_uring mkdirat/symlinkat/linkat support
    io_uring fixes
    libata fixes
    CDROM maintainer update
    block fixes
    libata maintainer update
    block fixes
    io_uring fixes

Jessica Yu (1):
    module updates

Jiri Kosina (1):
    HID updates

Joerg Roedel (2):
    iommu updates
    iommu fixes

Jon Mason (1):
    NTB updates

Jonathan Corbet (2):
    documentation updates
    more documentation updates

Juergen Gross (1):
    xen updates

Julia Lawall (1):
    coccinelle updates

Kees Cook (1):
    hardening updates

Konrad Rzeszutek Wilk (3):
    ibft updates
    swiotlb updates
    ibft fix

Konstantin Komarov (1):
    NTFSv3 filesystem

Lee Jones (2):
    MFD updates
    backlight updates

Linus Walleij (1):
    pin control updates

Mark Brown (3):
    regmap updates
    regulator updates
    spi updates

Masahiro Yamada (1):
    Kbuild updates

Mauro Carvalho Chehab (1):
    media updates

Max Filippov (1):
    Xtensa updates

Michael Ellerman (1):
    powerpc updates

Michael Tsirkin (1):
    virtio updates

Michal Simek (1):
    microblaze update

Miguel Ojeda (2):
    auxdisplay updates
    compiler attributes updates

Mike Rapoport (1):
    memblock updates

Mike Snitzer (1):
    device mapper updates

Miklos Szeredi (2):
    overlayfs update
    fuse updates

Mimi Zohar (1):
    integrity subsystem updates

Miquel Raynal (1):
    MTD updates

Palmer Dabbelt (2):
    RISC-V updates
    more RISC-V updates

Paolo Bonzini (1):
    KVM updates

Paul McKenney (1):
    RCU updates

Paul Moore (2):
    selinux update
    audit updates

Pavel Machek (1):
    LED updates

Petr Mladek (2):
    printk updates
    livepatching update

Rafael Wysocki (7):
    power management updates
    ACPI updates
    device properties framework updates
    more ACPI updates
    more power management updates
    more power management updates
    more ACPI updates

Richard Weinberger (1):
    UML updates

Rob Herring (2):
    devicetree updates
    devicetree fixes

Russell King (1):
    ARM development updates

Sebastian Reichel (1):
    power supply and reset updates

Shuah Khan (2):
    KUnit updates
    Kselftest updates

Stafford Horne (1):
    OpenRISC updates

Stefan Richter (1):
    firewire updates

Stephen Boyd (2):
    clk updates
    clk fix

Steve French (4):
    initial ksmbd implementation
    cifs client updates
    ksmbd fixes
    smbfs updates

Steven Rostedt (3):
    tracing updates
    more tracing updates
    tracing fixes

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (1):
    ext4 updates

Tejun Heo (2):
    cgroup updates
    workqueue updates

Thierry Reding (1):
    pwm updates

Thomas Bogendoerfer (1):
    MIPS updates

Thomas Gleixner (9):
    debugobjects update
    SMP core updates
    locking and atomics updates
    irq updates
    x86 cache flush updates
    x86 PIRQ updates
    misc x86 updates
    timer updates
    CPU hotplug updates

Ulf Hansson (1):
    MMC and MEMSTICK updates

Vineet Gupta (1):
    ARC updates

Vinod Koul (1):
    dmaengine updates

Vlastimil Babka (1):
    SLUB updates

Wei Liu (1):
    hyperv updates

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (1):
    i2c updates

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-12 23:58 Linux 5.15-rc1 Linus Torvalds
@ 2021-09-13  3:57 ` Guenter Roeck
  2021-09-28 23:18   ` Michael S. Tsirkin
  2021-09-13 14:18 ` Dave Jones
  1 sibling, 1 reply; 53+ messages in thread
From: Guenter Roeck @ 2021-09-13  3:57 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On Sun, Sep 12, 2021 at 04:58:27PM -0700, Linus Torvalds wrote:
[ ... ]
> 
> And in order to get those fixes going, please go out and test this.
> 

Build results:
	total: 153 pass: 143 fail: 10
Failed builds:
	alpha:allmodconfig (15)
	arm:allmodconfig (1)
	m68k:allmodconfig (47)
	mips:allmodconfig (2)
	parisc:allmodconfig (8)
	riscv32:allmodconfig (1)
	riscv:allmodconfig (1)
	s390:allmodconfig (6)
	sparc64:allmodconfig (1)
	xtensa:allmodconfig (53)
Qemu test results:
	total: 479 pass: 478 fail: 1
Failed tests:
	sparc64:sun4u:nodebug:smp:virtio-pci:net,i82559er:hd

The allmodconfig build failures are mostly if not all the result of
enabling -Werror on test builds. The individual errors are too many
to list; the number of errors is listed in () after the build above.
Anyone interested can find build logs at https://kerneltests.org/builders.
I am not entirely sure what to do about that - if history teaches a
lesson, new build failures may pile up faster than existing ones get
fixed, but then I am aware that several fixes are queued already. We'll
see how it goes. I'll monitor the situation until maybe -rc4 or -rc5 and
then decide if I disable -Werror in my test builds to catch any new "real"
problems.

The qemu runtime failure bisects to commit 694a1116b405 ("virtio: Bind
virtio device to device-tree node"), and reverting that commit fixes the
problem.  With that patch applied, the virtio block device does not
instantiate on sparc64. This results in a crash since that is where the
test is trying to boot from.

Good news is that I don't see any new runtime warnings.

Guenter

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-12 23:58 Linux 5.15-rc1 Linus Torvalds
  2021-09-13  3:57 ` Guenter Roeck
@ 2021-09-13 14:18 ` Dave Jones
  2021-09-13 18:59   ` Heiner Kallweit
  2021-09-13 23:46   ` Bjorn Helgaas
  1 sibling, 2 replies; 53+ messages in thread
From: Dave Jones @ 2021-09-13 14:18 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Heiner Kallweit

On Sun, Sep 12, 2021 at 04:58:27PM -0700, Linus Torvalds wrote:
 > So 5.15 isn't shaping up to be a particularly large release, at least
 > in number of commits. At only just over 10k non-merge commits, this is
 > in fact the smallest rc1 we have had in the 5.x series. We're usually
 > hovering in the 12-14k commit range.

This release takes over two minutes longer to boot on one my machines than 5.14.
The time just seems to be unaccounted for, even with initcall_debug

[    2.190051] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-fe])
[    2.190057] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    2.190239] acpi PNP0A08:00: _OSC: platform does not support [PME]
[    2.190360] acpi PNP0A08:00: _OSC: OS now controls [AER PCIeCapability LTR]
[    2.190362] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
[    2.190783] PCI host bridge to bus 0000:00
[    2.190785] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
[    2.190787] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
[    2.190789] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[    2.190790] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff window]
[    2.190792] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff window]
[    2.190794] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff window]
[    2.190795] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff window]
[    2.190797] pci_bus 0000:00: root bus resource [mem 0xbf200000-0xfeafffff window]
[    2.190799] pci_bus 0000:00: root bus resource [bus 00-fe]
[    2.190828] pci 0000:00:00.0: calling  quirk_mmio_always_on+0x0/0x10 @ 1
[    2.190833] pci 0000:00:00.0: quirk_mmio_always_on+0x0/0x10 took 0 usecs
[    2.190836] pci 0000:00:00.0: [8086:0c00] type 00 class 0x060000
[    2.190851] pci 0000:00:00.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.190855] pci 0000:00:00.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.190950] pci 0000:00:01.0: calling  quirk_no_aersid+0x0/0x10 @ 1
[    2.190953] pci 0000:00:01.0: quirk_no_aersid+0x0/0x10 took 0 usecs
[    2.190955] pci 0000:00:01.0: [8086:0c01] type 01 class 0x060400
[    2.190972] pci 0000:00:01.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.190975] pci 0000:00:01.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.190978] pci 0000:00:01.0: calling  pci_fixup_transparent_bridge+0x0/0x20 @ 1
[    2.190981] pci 0000:00:01.0: pci_fixup_transparent_bridge+0x0/0x20 took 0 usecs
[    2.190993] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    2.191233] pci 0000:00:02.0: [8086:0412] type 00 class 0x030000
[    2.191240] pci 0000:00:02.0: reg 0x10: [mem 0xdf000000-0xdf3fffff 64bit]
[    2.191244] pci 0000:00:02.0: reg 0x18: [mem 0xc0000000-0xcfffffff 64bit pref]
[    2.191248] pci 0000:00:02.0: reg 0x20: [io  0xf000-0xf03f]
[    2.191256] pci 0000:00:02.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.191260] pci 0000:00:02.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.191339] pci 0000:00:03.0: [8086:0c0c] type 00 class 0x040300
[    2.191345] pci 0000:00:03.0: reg 0x10: [mem 0xdfe34000-0xdfe37fff 64bit]
[    2.191356] pci 0000:00:03.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.191359] pci 0000:00:03.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.191450] pci 0000:00:14.0: [8086:8cb1] type 00 class 0x0c0330
[    2.191463] pci 0000:00:14.0: reg 0x10: [mem 0xdfe20000-0xdfe2ffff 64bit]
[    2.191492] pci 0000:00:14.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.191495] pci 0000:00:14.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.191514] pci 0000:00:14.0: PME# supported from D3hot D3cold
[    2.191592] pci 0000:00:16.0: [8086:8cba] type 00 class 0x078000
[    2.191606] pci 0000:00:16.0: reg 0x10: [mem 0xdfe3e000-0xdfe3e00f 64bit]
[    2.191637] pci 0000:00:16.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.191640] pci 0000:00:16.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.191660] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold
[    2.191790] pci 0000:00:19.0: calling  quirk_f0_vpd_link+0x0/0x60 @ 1
[    2.191794] pci 0000:00:19.0: quirk_f0_vpd_link+0x0/0x60 took 0 usecs
[    2.191797] pci 0000:00:19.0: [8086:15a1] type 00 class 0x020000
[    2.191807] pci 0000:00:19.0: reg 0x10: [mem 0xdfe00000-0xdfe1ffff]
[    2.191814] pci 0000:00:19.0: reg 0x14: [mem 0xdfe3c000-0xdfe3cfff]
[    2.191820] pci 0000:00:19.0: reg 0x18: [io  0xf080-0xf09f]
[    2.191844] pci 0000:00:19.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.191847] pci 0000:00:19.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.191869] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
[    2.191953] pci 0000:00:1a.0: [8086:8cad] type 00 class 0x0c0320
[    2.191966] pci 0000:00:1a.0: reg 0x10: [mem 0xdfe3b000-0xdfe3b3ff]
[    2.192007] pci 0000:00:1a.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.192010] pci 0000:00:1a.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.192038] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
[    2.192121] pci 0000:00:1b.0: [8086:8ca0] type 00 class 0x040300
[    2.192132] pci 0000:00:1b.0: reg 0x10: [mem 0xdfe30000-0xdfe33fff 64bit]
[    2.192158] pci 0000:00:1b.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.192161] pci 0000:00:1b.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.192187] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[    2.192313] pci 0000:00:1c.0: calling  quirk_no_aersid+0x0/0x10 @ 1
[    2.192316] pci 0000:00:1c.0: quirk_no_aersid+0x0/0x10 took 0 usecs
[    2.192318] pci 0000:00:1c.0: [8086:8c90] type 01 class 0x060400
[    2.192353] pci 0000:00:1c.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.192356] pci 0000:00:1c.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.192359] pci 0000:00:1c.0: calling  pci_fixup_transparent_bridge+0x0/0x20 @ 1
[    2.192362] pci 0000:00:1c.0: pci_fixup_transparent_bridge+0x0/0x20 took 0 usecs
[    2.192387] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    2.192615] pci 0000:00:1c.3: calling  quirk_no_aersid+0x0/0x10 @ 1
[    2.192618] pci 0000:00:1c.3: quirk_no_aersid+0x0/0x10 took 0 usecs
[    2.192620] pci 0000:00:1c.3: [8086:8c96] type 01 class 0x060400
[    2.192656] pci 0000:00:1c.3: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.192659] pci 0000:00:1c.3: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.192662] pci 0000:00:1c.3: calling  pci_fixup_transparent_bridge+0x0/0x20 @ 1
[    2.192664] pci 0000:00:1c.3: pci_fixup_transparent_bridge+0x0/0x20 took 0 usecs
[    2.192689] pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
[    2.192914] pci 0000:00:1c.4: calling  quirk_no_aersid+0x0/0x10 @ 1
[    2.192917] pci 0000:00:1c.4: quirk_no_aersid+0x0/0x10 took 0 usecs
[    2.192919] pci 0000:00:1c.4: [8086:8c98] type 01 class 0x060400
[    2.192954] pci 0000:00:1c.4: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.192957] pci 0000:00:1c.4: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.192960] pci 0000:00:1c.4: calling  pci_fixup_transparent_bridge+0x0/0x20 @ 1
[    2.192962] pci 0000:00:1c.4: pci_fixup_transparent_bridge+0x0/0x20 took 0 usecs
[    2.192988] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    2.193213] pci 0000:00:1c.6: calling  quirk_no_aersid+0x0/0x10 @ 1
[    2.193215] pci 0000:00:1c.6: quirk_no_aersid+0x0/0x10 took 0 usecs
[    2.193217] pci 0000:00:1c.6: [8086:8c9c] type 01 class 0x060400
[    2.193253] pci 0000:00:1c.6: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.193256] pci 0000:00:1c.6: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.193259] pci 0000:00:1c.6: calling  pci_fixup_transparent_bridge+0x0/0x20 @ 1
[    2.193261] pci 0000:00:1c.6: pci_fixup_transparent_bridge+0x0/0x20 took 0 usecs
[    2.193286] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold
[    2.193515] pci 0000:00:1d.0: [8086:8ca6] type 00 class 0x0c0320
[    2.193528] pci 0000:00:1d.0: reg 0x10: [mem 0xdfe3a000-0xdfe3a3ff]
[    2.193570] pci 0000:00:1d.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.193573] pci 0000:00:1d.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.193601] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[    2.193688] pci 0000:00:1f.0: [8086:8cc4] type 00 class 0x060100
[    2.193754] pci 0000:00:1f.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.193757] pci 0000:00:1f.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.193855] pci 0000:00:1f.2: [8086:8c82] type 00 class 0x010601
[    2.193864] pci 0000:00:1f.2: reg 0x10: [io  0xf0d0-0xf0d7]
[    2.193870] pci 0000:00:1f.2: reg 0x14: [io  0xf0c0-0xf0c3]
[    2.193875] pci 0000:00:1f.2: reg 0x18: [io  0xf0b0-0xf0b7]
[    2.193881] pci 0000:00:1f.2: reg 0x1c: [io  0xf0a0-0xf0a3]
[    2.193886] pci 0000:00:1f.2: reg 0x20: [io  0xf060-0xf07f]
[    2.193892] pci 0000:00:1f.2: reg 0x24: [mem 0xdfe39000-0xdfe397ff]
[    2.193901] pci 0000:00:1f.2: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.193904] pci 0000:00:1f.2: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.193923] pci 0000:00:1f.2: PME# supported from D3hot
[    2.193997] pci 0000:00:1f.3: [8086:8ca2] type 00 class 0x0c0500
[    2.194010] pci 0000:00:1f.3: reg 0x10: [mem 0xdfe38000-0xdfe380ff 64bit]
[    2.194025] pci 0000:00:1f.3: reg 0x20: [io  0xf040-0xf05f]
[    2.194039] pci 0000:00:1f.3: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.194042] pci 0000:00:1f.3: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.194093] pci 0000:01:00.0: calling  quirk_f0_vpd_link+0x0/0x60 @ 1
[    2.194097] pci 0000:01:00.0: quirk_f0_vpd_link+0x0/0x60 took 0 usecs
[    2.194100] pci 0000:01:00.0: [8086:10fb] type 00 class 0x020000
[    2.194109] pci 0000:01:00.0: reg 0x10: [mem 0xd0080000-0xd00fffff 64bit pref]
[    2.194113] pci 0000:01:00.0: reg 0x18: [io  0xe020-0xe03f]
[    2.194121] pci 0000:01:00.0: reg 0x20: [mem 0xd0104000-0xd0107fff 64bit pref]
[    2.194126] pci 0000:01:00.0: reg 0x30: [mem 0xdfd80000-0xdfdfffff pref]
[    2.194136] pci 0000:01:00.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[    2.194139] pci 0000:01:00.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[    2.194164] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold

* stall here for 86 seconds *

[   88.675114] pci 0000:01:00.0: reg 0x184: [mem 0x00000000-0x00003fff 64bit pref]
[   88.675118] pci 0000:01:00.0: VF(n) BAR0 space: [mem 0x00000000-0x000fffff 64bit pref] (contains BAR0 for 64 VFs)
[   88.675125] pci 0000:01:00.0: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[   88.675127] pci 0000:01:00.0: VF(n) BAR3 space: [mem 0x00000000-0x000fffff 64bit pref] (contains BAR3 for 64 VFs)
[   88.675252] pci 0000:01:00.1: calling  quirk_f0_vpd_link+0x0/0x60 @ 1
[   88.675255] pci 0000:01:00.1: quirk_f0_vpd_link+0x0/0x60 took 0 usecs
[   88.675258] pci 0000:01:00.1: [8086:10fb] type 00 class 0x020000
[   88.675267] pci 0000:01:00.1: reg 0x10: [mem 0xd0000000-0xd007ffff 64bit pref]
[   88.675272] pci 0000:01:00.1: reg 0x18: [io  0xe000-0xe01f]
[   88.675280] pci 0000:01:00.1: reg 0x20: [mem 0xd0100000-0xd0103fff 64bit pref]
[   88.675284] pci 0000:01:00.1: reg 0x30: [mem 0xdfd00000-0xdfd7ffff pref]
[   88.675295] pci 0000:01:00.1: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[   88.675298] pci 0000:01:00.1: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[   88.675324] pci 0000:01:00.1: PME# supported from D0 D3hot D3cold

* stall again for 98 seconds *

[  186.595114] pci 0000:01:00.1: reg 0x184: [mem 0x00000000-0x00003fff 64bit pref]
[  186.595117] pci 0000:01:00.1: VF(n) BAR0 space: [mem 0x00000000-0x000fffff 64bit pref] (contains BAR0 for 64 VFs)
[  186.595124] pci 0000:01:00.1: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[  186.595126] pci 0000:01:00.1: VF(n) BAR3 space: [mem 0x00000000-0x000fffff 64bit pref] (contains BAR3 for 64 VFs)
[  186.595242] pci 0000:00:01.0: PCI bridge to [bus 01]
[  186.595245] pci 0000:00:01.0:   bridge window [io  0xe000-0xefff]
[  186.595247] pci 0000:00:01.0:   bridge window [mem 0xdfd00000-0xdfdfffff]
[  186.595249] pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xd01fffff 64bit pref]
[  186.595251] pci 0000:00:01.0: bridge has subordinate 01 but max busn 02
[  186.595296] pci 0000:02:00.0: [144d:a800] type 00 class 0x010601
[  186.595351] pci 0000:02:00.0: reg 0x24: [mem 0xdfc10000-0xdfc11fff]
[  186.595361] pci 0000:02:00.0: reg 0x30: [mem 0xdfc00000-0xdfc0ffff pref]
[  186.595425] pci 0000:02:00.0: PME# supported from D3hot D3cold
[  186.735107] pci 0000:02:00.0: VPD access failed.  This is likely a firmware bug on this device.  Contact the card vendor for a firmware update
[  186.735140] pci 0000:02:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x2 link at 0000:00:1c.0 (capable of 16.000 Gb/s with 5.0 GT/s PCIe x4 link)
[  186.735255] pci 0000:00:1c.0: PCI bridge to [bus 02]
[  186.735260] pci 0000:00:1c.0:   bridge window [mem 0xdfc00000-0xdfcfffff]
[  186.735310] pci 0000:03:00.0: [1b21:1187] type 01 class 0x060400
[  186.735360] pci 0000:03:00.0: enabling Extended Tags
[  186.735422] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
[  186.735567] pci 0000:00:1c.3: PCI bridge to [bus 03-0b]
[  186.735570] pci 0000:00:1c.3:   bridge window [io  0xb000-0xcfff]
[  186.735573] pci 0000:00:1c.3:   bridge window [mem 0xdf400000-0xdf9fffff]
[  186.735649] pci 0000:04:01.0: [1b21:1187] type 01 class 0x060400
[  186.735702] pci 0000:04:01.0: enabling Extended Tags
[  186.735762] pci 0000:04:01.0: PME# supported from D0 D3hot D3cold
[  186.735848] pci 0000:04:02.0: [1b21:1187] type 01 class 0x060400
[  186.735901] pci 0000:04:02.0: enabling Extended Tags
[  186.735961] pci 0000:04:02.0: PME# supported from D0 D3hot D3cold
[  186.736048] pci 0000:04:03.0: [1b21:1187] type 01 class 0x060400
[  186.736100] pci 0000:04:03.0: enabling Extended Tags
[  186.736160] pci 0000:04:03.0: PME# supported from D0 D3hot D3cold
[  186.736243] pci 0000:04:04.0: [1b21:1187] type 01 class 0x060400
[  186.736296] pci 0000:04:04.0: enabling Extended Tags
[  186.736355] pci 0000:04:04.0: PME# supported from D0 D3hot D3cold
[  186.736439] pci 0000:04:05.0: [1b21:1187] type 01 class 0x060400
[  186.736492] pci 0000:04:05.0: enabling Extended Tags
[  186.736551] pci 0000:04:05.0: PME# supported from D0 D3hot D3cold
[  186.736635] pci 0000:04:06.0: [1b21:1187] type 01 class 0x060400
[  186.736688] pci 0000:04:06.0: enabling Extended Tags
[  186.736747] pci 0000:04:06.0: PME# supported from D0 D3hot D3cold
[  186.736830] pci 0000:04:07.0: [1b21:1187] type 01 class 0x060400
[  186.736883] pci 0000:04:07.0: enabling Extended Tags
[  186.736943] pci 0000:04:07.0: PME# supported from D0 D3hot D3cold
[  186.737024] pci 0000:03:00.0: PCI bridge to [bus 04-0b]
[  186.737030] pci 0000:03:00.0:   bridge window [io  0xb000-0xcfff]
[  186.737034] pci 0000:03:00.0:   bridge window [mem 0xdf400000-0xdf9fffff]
[  186.737071] pci 0000:04:01.0: PCI bridge to [bus 05]
[  186.737153] pci 0000:06:00.0: [14e4:43b1] type 00 class 0x028000
[  186.737183] pci 0000:06:00.0: reg 0x10: [mem 0xdf600000-0xdf607fff 64bit]
[  186.737202] pci 0000:06:00.0: reg 0x18: [mem 0xdf400000-0xdf5fffff 64bit]
[  186.737372] pci 0000:06:00.0: supports D1 D2
[  186.737374] pci 0000:06:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[  186.737516] pci 0000:04:02.0: PCI bridge to [bus 06]
[  186.737524] pci 0000:04:02.0:   bridge window [mem 0xdf400000-0xdf6fffff]
[  186.737586] pci 0000:07:00.0: calling  fixup_mpss_256+0x0/0x20 @ 1
[  186.737590] pci 0000:07:00.0: fixup_mpss_256+0x0/0x20 took 0 usecs
[  186.737593] pci 0000:07:00.0: [1b21:0612] type 00 class 0x010601
[  186.737617] pci 0000:07:00.0: reg 0x10: [io  0xc050-0xc057]
[  186.737630] pci 0000:07:00.0: reg 0x14: [io  0xc040-0xc043]
[  186.737643] pci 0000:07:00.0: reg 0x18: [io  0xc030-0xc037]
[  186.737657] pci 0000:07:00.0: reg 0x1c: [io  0xc020-0xc023]
[  186.737670] pci 0000:07:00.0: reg 0x20: [io  0xc000-0xc01f]
[  186.737683] pci 0000:07:00.0: reg 0x24: [mem 0xdf900000-0xdf9001ff]
[  186.737851] pci 0000:04:03.0: PCI bridge to [bus 07]
[  186.737857] pci 0000:04:03.0:   bridge window [io  0xc000-0xcfff]
[  186.737860] pci 0000:04:03.0:   bridge window [mem 0xdf900000-0xdf9fffff]
[  186.737899] pci 0000:04:04.0: PCI bridge to [bus 08]
[  186.737943] pci 0000:04:05.0: PCI bridge to [bus 09]
[  186.738025] pci 0000:0a:00.0: calling  quirk_f0_vpd_link+0x0/0x60 @ 1
[  186.738028] pci 0000:0a:00.0: quirk_f0_vpd_link+0x0/0x60 took 0 usecs
[  186.738031] pci 0000:0a:00.0: [8086:1539] type 00 class 0x020000
[  186.738058] pci 0000:0a:00.0: reg 0x10: [mem 0xdf800000-0xdf81ffff]
[  186.738082] pci 0000:0a:00.0: reg 0x18: [io  0xb000-0xb01f]
[  186.738095] pci 0000:0a:00.0: reg 0x1c: [mem 0xdf820000-0xdf823fff]
[  186.738159] pci 0000:0a:00.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
[  186.738162] pci 0000:0a:00.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
[  186.738265] pci 0000:0a:00.0: PME# supported from D0 D3hot D3cold
[  186.738397] pci 0000:04:06.0: PCI bridge to [bus 0a]
[  186.738403] pci 0000:04:06.0:   bridge window [io  0xb000-0xbfff]
[  186.738407] pci 0000:04:06.0:   bridge window [mem 0xdf800000-0xdf8fffff]
[  186.738448] pci 0000:04:07.0: PCI bridge to [bus 0b]
[  186.738540] pci 0000:0c:00.0: calling  fixup_mpss_256+0x0/0x20 @ 1
[  186.738543] pci 0000:0c:00.0: fixup_mpss_256+0x0/0x20 took 0 usecs
[  186.738546] pci 0000:0c:00.0: [1b21:0612] type 00 class 0x010601
[  186.738563] pci 0000:0c:00.0: reg 0x10: [io  0xd050-0xd057]
[  186.738572] pci 0000:0c:00.0: reg 0x14: [io  0xd040-0xd043]
[  186.738582] pci 0000:0c:00.0: reg 0x18: [io  0xd030-0xd037]
[  186.738591] pci 0000:0c:00.0: reg 0x1c: [io  0xd020-0xd023]
[  186.738601] pci 0000:0c:00.0: reg 0x20: [io  0xd000-0xd01f]
[  186.738610] pci 0000:0c:00.0: reg 0x24: [mem 0xdfb00000-0xdfb001ff]
[  186.738799] pci 0000:00:1c.4: PCI bridge to [bus 0c]
[  186.738802] pci 0000:00:1c.4:   bridge window [io  0xd000-0xdfff]
[  186.738805] pci 0000:00:1c.4:   bridge window [mem 0xdfb00000-0xdfbfffff]
[  186.738855] pci 0000:0d:00.0: [1b21:1142] type 00 class 0x0c0330
[  186.738881] pci 0000:0d:00.0: reg 0x10: [mem 0xdfa00000-0xdfa07fff 64bit]
[  186.739001] pci 0000:0d:00.0: PME# supported from D3cold
[  186.739136] pci 0000:00:1c.6: PCI bridge to [bus 0d]
[  186.739140] pci 0000:00:1c.6:   bridge window [mem 0xdfa00000-0xdfafffff]
[  186.739160] pci_bus 0000:00: on NUMA node 0


* boot seems to continue as normal from here *


I did a bisect, which landed in the VPD rework that Heiner landed in
this merge window.   Specifically it ended up on ...


git bisect start
# good: [7d2a07b769330c34b4deabeed939325c77a7ec2f] Linux 5.14
git bisect good 7d2a07b769330c34b4deabeed939325c77a7ec2f
# bad: [6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f] Linux 5.15-rc1
git bisect bad 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f
# good: [1b4f3dfb4792f03b139edf10124fcbeb44e608e6] Merge tag 'usb-serial-5.15-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next                                              
git bisect good 1b4f3dfb4792f03b139edf10124fcbeb44e608e6
# good: [c793011242d182e5f12800c12dbaf37af80be735] Merge tag 'pinctrl-v5.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl                                                              
git bisect good c793011242d182e5f12800c12dbaf37af80be735
# good: [5e6a5845dd651b00754a62edec2f0a439182024d] Merge tag 'gpio-updates-for-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux                                                                 
git bisect good 5e6a5845dd651b00754a62edec2f0a439182024d
# bad: [0f4b9289bad354b606190a4cd54d5222b4e41d98] Merge tag 'docs-5.15-2' of git://git.lwn.net/linux
git bisect bad 0f4b9289bad354b606190a4cd54d5222b4e41d98
# good: [626bf91a292e2035af5b9d9cce35c5c138dfe06d] Merge tag 'net-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net                                                                           
git bisect good 626bf91a292e2035af5b9d9cce35c5c138dfe06d
# bad: [49832c819ab85b33b7a2a1429c8d067e82be2977] Makefile: use -Wno-main in the full kernel tree
git bisect bad 49832c819ab85b33b7a2a1429c8d067e82be2977
# bad: [739c4747a25af3a2571f69e4709f2b476a17d5d4] Merge branch 'pci/misc'
git bisect bad 739c4747a25af3a2571f69e4709f2b476a17d5d4
# bad: [2c208abd4f9efac02622d8f3c9989f4b7b1ad973] PCI/VPD: Use unaligned access helpers
git bisect bad 2c208abd4f9efac02622d8f3c9989f4b7b1ad973
# bad: [f240e15097c5004811a58f2cbc170bf90d06d0a9] tg3: Read VPD with pci_vpd_alloc()
git bisect bad f240e15097c5004811a58f2cbc170bf90d06d0a9
# good: [d27f7344ba89897d0ce6ebe0c9eecbe214f9bb8f] PCI/VPD: Reorder pci_read_vpd(), pci_write_vpd()
git bisect good d27f7344ba89897d0ce6ebe0c9eecbe214f9bb8f
# bad: [fe7568cf2f2dc3a0783f6ffdb3802c1ce2085466] PCI/VPD: Treat invalid VPD like missing VPD capability
git bisect bad fe7568cf2f2dc3a0783f6ffdb3802c1ce2085466
# good: [22ff2bcec704a7a8c43a998251e0757cd2de66e1] PCI/VPD: Remove struct pci_vpd.valid member
git bisect good 22ff2bcec704a7a8c43a998251e0757cd2de66e1
# bad: [7bac54497c3e3b2ca37b7043f1fa78586540f10e] PCI/VPD: Determine VPD size in pci_vpd_init()
git bisect bad 7bac54497c3e3b2ca37b7043f1fa78586540f10e
# good: [fd00faa375fbb9d46ae0730d0faf4a3006301005] PCI/VPD: Embed struct pci_vpd in struct pci_dev
git bisect good fd00faa375fbb9d46ae0730d0faf4a3006301005
# first bad commit: [7bac54497c3e3b2ca37b7043f1fa78586540f10e] PCI/VPD: Determine VPD size in pci_vpd_init()   

7bac54497c3e3b2ca37b7043f1fa78586540f10e is the first bad commit
commit 7bac54497c3e3b2ca37b7043f1fa78586540f10e
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sun Aug 8 19:22:52 2021 +0200

    PCI/VPD: Determine VPD size in pci_vpd_init()

    Determine VPD size in pci_vpd_init().

    Quirks set dev->vpd.len to a non-zero value, so they cause us to skip the
    dynamic size calculation.  Prerequisite is that we move the quirks from
    FINAL to HEADER so they are run before pci_vpd_init().

    Link: https://lore.kernel.org/r/cc4a6538-557a-294d-4f94-e6d1d3c91589@gmail.com
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>


Which unfortunately doesn't revert cleanly I can't test it reverted in
isolation.

My guess is there's something quirky about the PCI bus on this machine
that causes stalls until we hit timeout, but I'm not sure where to begin
debugging this.

There's nothing too exotic on this machine:

00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 9 Series Chipset Family USB xHCI Controller
00:16.0 Communication controller: Intel Corporation 9 Series Chipset Family ME Interface #1
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V
00:1a.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #2
00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller
00:1c.0 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 1 (rev d0)
00:1c.3 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 4 (rev d0)
00:1c.4 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 5 (rev d0)
00:1c.6 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 7 (rev d0)
00:1d.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #1
00:1f.0 ISA bridge: Intel Corporation Z97 Chipset LPC Controller
00:1f.2 SATA controller: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode]
00:1f.3 SMBus: Intel Corporation 9 Series Chipset Family SMBus Controller
01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
02:00.0 SATA controller: Samsung Electronics Co Ltd XP941 PCIe SSD (rev 01)
03:00.0 PCI bridge: ASMedia Technology Inc. Device 1187
04:01.0 PCI bridge: ASMedia Technology Inc. Device 1187
04:02.0 PCI bridge: ASMedia Technology Inc. Device 1187
04:03.0 PCI bridge: ASMedia Technology Inc. Device 1187
04:04.0 PCI bridge: ASMedia Technology Inc. Device 1187
04:05.0 PCI bridge: ASMedia Technology Inc. Device 1187
04:06.0 PCI bridge: ASMedia Technology Inc. Device 1187
04:07.0 PCI bridge: ASMedia Technology Inc. Device 1187
06:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4352 802.11ac Wireless Network Adapter (rev 03)
07:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)
0a:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
0c:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)
0d:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller


	Dave


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 14:18 ` Dave Jones
@ 2021-09-13 18:59   ` Heiner Kallweit
  2021-09-13 19:51     ` Linus Torvalds
  2021-09-13 20:15     ` Dave Jones
  2021-09-13 23:46   ` Bjorn Helgaas
  1 sibling, 2 replies; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-13 18:59 UTC (permalink / raw)
  To: Dave Jones, Linus Torvalds, Linux Kernel Mailing List, Bjorn Helgaas
  Cc: linux-pci

On 13.09.2021 16:18, Dave Jones wrote:
> [  186.595296] pci 0000:02:00.0: [144d:a800] type 00 class 0x010601
> [  186.595351] pci 0000:02:00.0: reg 0x24: [mem 0xdfc10000-0xdfc11fff]
> [  186.595361] pci 0000:02:00.0: reg 0x30: [mem 0xdfc00000-0xdfc0ffff pref]
> [  186.595425] pci 0000:02:00.0: PME# supported from D3hot D3cold
> [  186.735107] pci 0000:02:00.0: VPD access failed.  This is likely a firmware bug on this device.  Contact the card vendor for a firmware update

Thanks for the report! The stalls may be related to this one. Device is:
02:00.0 SATA controller: Samsung Electronics Co Ltd XP941 PCIe SSD (rev 01)

With an older kernel you may experience the stall when accessing the vpd
attribute of this device in sysfs.

Maybe the device indicates VPD capability but doesn't actually support it.
Could you please provide the "lspci -vv" output for this device?

And could you please test with the following applied to verify the
assumption? It disables VPD access for this device.

---
 drivers/pci/vpd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
index 517789205..fc92e880e 100644
--- a/drivers/pci/vpd.c
+++ b/drivers/pci/vpd.c
@@ -540,6 +540,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, quirk_blacklist_vpd);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, quirk_blacklist_vpd);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SAMSUNG, 0xa800, quirk_blacklist_vpd);
 /*
  * The Amazon Annapurna Labs 0x0031 device id is reused for other non Root Port
  * device types, so the quirk is registered for the PCI_CLASS_BRIDGE_PCI class.
-- 
2.33.0







^ permalink raw reply related	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 18:59   ` Heiner Kallweit
@ 2021-09-13 19:51     ` Linus Torvalds
  2021-09-13 20:09       ` Bjorn Helgaas
  2021-09-13 20:11       ` Heiner Kallweit
  2021-09-13 20:15     ` Dave Jones
  1 sibling, 2 replies; 53+ messages in thread
From: Linus Torvalds @ 2021-09-13 19:51 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Dave Jones, Linux Kernel Mailing List, Bjorn Helgaas, linux-pci

On Mon, Sep 13, 2021 at 12:00 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> With an older kernel you may experience the stall when accessing the vpd
> attribute of this device in sysfs.

Honestly, that old behavior seems to be the *much* better behavior.

A synchronous stall at boot time is truly annoying, and a pain to deal
with (and debug).

That pci_vpd_read() function is clearly NOT designed to deal with
boot-time callers in the first place, so I think that commit is simply
wrong.

And yes, I see that "128ms timeout". If it was _one_ timeout, that
would be one thing,. But it looks like it's repeated over and over.

Not acceptable at boot time. Not at all.

Bjorn. Please revert. Or I can do it.

            Linus

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 19:51     ` Linus Torvalds
@ 2021-09-13 20:09       ` Bjorn Helgaas
  2021-09-13 20:11       ` Heiner Kallweit
  1 sibling, 0 replies; 53+ messages in thread
From: Bjorn Helgaas @ 2021-09-13 20:09 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Heiner Kallweit, Dave Jones, Linux Kernel Mailing List,
	Bjorn Helgaas, linux-pci

On Mon, Sep 13, 2021 at 12:51:30PM -0700, Linus Torvalds wrote:
> On Mon, Sep 13, 2021 at 12:00 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >
> > With an older kernel you may experience the stall when accessing the vpd
> > attribute of this device in sysfs.
> 
> Honestly, that old behavior seems to be the *much* better behavior.
> 
> A synchronous stall at boot time is truly annoying, and a pain to deal
> with (and debug).
> 
> That pci_vpd_read() function is clearly NOT designed to deal with
> boot-time callers in the first place, so I think that commit is simply
> wrong.
> 
> And yes, I see that "128ms timeout". If it was _one_ timeout, that
> would be one thing,. But it looks like it's repeated over and over.
> 
> Not acceptable at boot time. Not at all.
> 
> Bjorn. Please revert. Or I can do it.

Sorry about this.

Dave said it wasn't a trivial revert, but I'll be happy to work with
Heiner and Dave to revert and test it.

I agree that we shouldn't read VPD at boot-time unless we actually
need the data then.

Bjorn

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 19:51     ` Linus Torvalds
  2021-09-13 20:09       ` Bjorn Helgaas
@ 2021-09-13 20:11       ` Heiner Kallweit
  2021-09-13 20:15         ` Linus Torvalds
  1 sibling, 1 reply; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-13 20:11 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Dave Jones, Linux Kernel Mailing List, Bjorn Helgaas, linux-pci

On 13.09.2021 21:51, Linus Torvalds wrote:
> On Mon, Sep 13, 2021 at 12:00 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>
>> With an older kernel you may experience the stall when accessing the vpd
>> attribute of this device in sysfs.
> 
> Honestly, that old behavior seems to be the *much* better behavior.
> 
> A synchronous stall at boot time is truly annoying, and a pain to deal
> with (and debug).
> 
> That pci_vpd_read() function is clearly NOT designed to deal with
> boot-time callers in the first place, so I think that commit is simply
> wrong.
> 
> And yes, I see that "128ms timeout". If it was _one_ timeout, that
> would be one thing,. But it looks like it's repeated over and over.
> 
No. The timeout is not the issue, otherwise you would see the message
"VPD access failed.."  over and over again. The issue here seems to be
that this call in PCI config space access to adress
vpd->cap + PCI_VPD_ADDR stalls.

In a first place this seems to be due to a buggy device. We'll know
for sure once Dave checks with the test patch applied. To deal with
such buggy devices we have the VPD blacklist quirk.

Secondly you could blame the PCI subsystem for not detecting stalled
access to a buggy device. However I don't know the PCIe spec good
enough to really comment on this.

> Not acceptable at boot time. Not at all.
> 
> Bjorn. Please revert. Or I can do it.
> 
>             Linus
> 
Heiner

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 18:59   ` Heiner Kallweit
  2021-09-13 19:51     ` Linus Torvalds
@ 2021-09-13 20:15     ` Dave Jones
  2021-09-13 20:22       ` Heiner Kallweit
  2021-09-13 20:32       ` Heiner Kallweit
  1 sibling, 2 replies; 53+ messages in thread
From: Dave Jones @ 2021-09-13 20:15 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Linus Torvalds, Linux Kernel Mailing List, Bjorn Helgaas, linux-pci

On Mon, Sep 13, 2021 at 08:59:49PM +0200, Heiner Kallweit wrote:
 > On 13.09.2021 16:18, Dave Jones wrote:
 > > [  186.595296] pci 0000:02:00.0: [144d:a800] type 00 class 0x010601
 > > [  186.595351] pci 0000:02:00.0: reg 0x24: [mem 0xdfc10000-0xdfc11fff]
 > > [  186.595361] pci 0000:02:00.0: reg 0x30: [mem 0xdfc00000-0xdfc0ffff pref]
 > > [  186.595425] pci 0000:02:00.0: PME# supported from D3hot D3cold
 > > [  186.735107] pci 0000:02:00.0: VPD access failed.  This is likely a firmware bug on this device.  Contact the card vendor for a firmware update
 > 
 > Thanks for the report! The stalls may be related to this one. Device is:
 > 02:00.0 SATA controller: Samsung Electronics Co Ltd XP941 PCIe SSD (rev 01)
 > 
 > With an older kernel you may experience the stall when accessing the vpd
 > attribute of this device in sysfs.
 > 
 > Maybe the device indicates VPD capability but doesn't actually support it.
 > Could you please provide the "lspci -vv" output for this device?

02:00.0 SATA controller: Samsung Electronics Co Ltd XP941 PCIe SSD (rev 01) (prog-if 01 [AHCI 1.0])
        Subsystem: Samsung Electronics Co Ltd XP941 PCIe SSD
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 5: Memory at dfc10000 (32-bit, non-prefetchable) [size=8K]
        Expansion ROM at dfc00000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [70] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 25.000W
                DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
                LnkCap: Port #0, Speed 5GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us
                        ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 5GT/s (ok), Width x2 (downgraded)
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis+ NROPrPrP- LTR+
                         10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
                         EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
                         FRS- TPHComp- ExtTPHComp-
                         AtomicOpsCap: 32bit- 64bit- 128bitCAS-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ OBFF Disabled,
                         AtomicOpsCtl: ReqEn-
                LnkCap2: Supported Link Speeds: 2.5-5GT/s, Crosslink- Retimer- 2Retimers- DRS-
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
                         EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
                         Retimer- 2Retimers- CrosslinkRes: unsupported
        Capabilities: [d0] Vital Product Data
                Not readable
        Capabilities: [100 v2] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
                HeaderLog: 00000000 00000000 00000000 00000000
        Capabilities: [140 v1] Device Serial Number 00-00-00-00-00-00-00-00
        Capabilities: [150 v1] Power Budgeting <?>
        Capabilities: [160 v1] Latency Tolerance Reporting
                Max snoop latency: 71680ns
                Max no snoop latency: 71680ns
        Kernel driver in use: ahci


 > And could you please test with the following applied to verify the
 > assumption? It disables VPD access for this device.
 > 
 > ---
 >  drivers/pci/vpd.c | 1 +
 >  1 file changed, 1 insertion(+)
 > 
 > diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
 > index 517789205..fc92e880e 100644
 > --- a/drivers/pci/vpd.c
 > +++ b/drivers/pci/vpd.c
 > @@ -540,6 +540,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, quirk_blacklist_vpd);
 >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, quirk_blacklist_vpd);
 >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd);
 >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
 > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SAMSUNG, 0xa800, quirk_blacklist_vpd);
 >  /*
 >   * The Amazon Annapurna Labs 0x0031 device id is reused for other non Root Port
 >   * device types, so the quirk is registered for the PCI_CLASS_BRIDGE_PCI class.


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


	Dave


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 20:11       ` Heiner Kallweit
@ 2021-09-13 20:15         ` Linus Torvalds
  0 siblings, 0 replies; 53+ messages in thread
From: Linus Torvalds @ 2021-09-13 20:15 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Dave Jones, Linux Kernel Mailing List, Bjorn Helgaas, linux-pci

On Mon, Sep 13, 2021 at 1:11 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> No. The timeout is not the issue, otherwise you would see the message
> "VPD access failed.."  over and over again.

Ahh, I did check that that error did exist, but you're right, it's not
there all the time.

> The issue here seems to be
> that this call in PCI config space access to adress
> vpd->cap + PCI_VPD_ADDR stalls.

Ok. Regardless, we shouldn't do this since the boot code shouldn't
need any of the VPD information.

        Linus

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 20:15     ` Dave Jones
@ 2021-09-13 20:22       ` Heiner Kallweit
  2021-09-13 20:32         ` Dave Jones
  2021-09-13 20:32       ` Heiner Kallweit
  1 sibling, 1 reply; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-13 20:22 UTC (permalink / raw)
  To: Dave Jones, Linus Torvalds, Linux Kernel Mailing List,
	Bjorn Helgaas, linux-pci

On 13.09.2021 22:15, Dave Jones wrote:
> On Mon, Sep 13, 2021 at 08:59:49PM +0200, Heiner Kallweit wrote:
>  > On 13.09.2021 16:18, Dave Jones wrote:
>  > > [  186.595296] pci 0000:02:00.0: [144d:a800] type 00 class 0x010601
>  > > [  186.595351] pci 0000:02:00.0: reg 0x24: [mem 0xdfc10000-0xdfc11fff]
>  > > [  186.595361] pci 0000:02:00.0: reg 0x30: [mem 0xdfc00000-0xdfc0ffff pref]
>  > > [  186.595425] pci 0000:02:00.0: PME# supported from D3hot D3cold
>  > > [  186.735107] pci 0000:02:00.0: VPD access failed.  This is likely a firmware bug on this device.  Contact the card vendor for a firmware update
>  > 
>  > Thanks for the report! The stalls may be related to this one. Device is:
>  > 02:00.0 SATA controller: Samsung Electronics Co Ltd XP941 PCIe SSD (rev 01)
>  > 
>  > With an older kernel you may experience the stall when accessing the vpd
>  > attribute of this device in sysfs.
>  > 
>  > Maybe the device indicates VPD capability but doesn't actually support it.
>  > Could you please provide the "lspci -vv" output for this device?
> 
> 02:00.0 SATA controller: Samsung Electronics Co Ltd XP941 PCIe SSD (rev 01) (prog-if 01 [AHCI 1.0])
>         Subsystem: Samsung Electronics Co Ltd XP941 PCIe SSD
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0, Cache Line Size: 64 bytes
>         Interrupt: pin A routed to IRQ 16
>         Region 5: Memory at dfc10000 (32-bit, non-prefetchable) [size=8K]
>         Expansion ROM at dfc00000 [disabled] [size=64K]
>         Capabilities: [40] Power Management version 3
>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [70] Express (v2) Endpoint, MSI 00
>                 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
>                         ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 25.000W
>                 DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
>                         RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
>                         MaxPayload 128 bytes, MaxReadReq 512 bytes
>                 DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
>                 LnkCap: Port #0, Speed 5GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us
>                         ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
>                 LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                 LnkSta: Speed 5GT/s (ok), Width x2 (downgraded)
>                         TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>                 DevCap2: Completion Timeout: Not Supported, TimeoutDis+ NROPrPrP- LTR+
>                          10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
>                          EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
>                          FRS- TPHComp- ExtTPHComp-
>                          AtomicOpsCap: 32bit- 64bit- 128bitCAS-
>                 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ OBFF Disabled,
>                          AtomicOpsCtl: ReqEn-
>                 LnkCap2: Supported Link Speeds: 2.5-5GT/s, Crosslink- Retimer- 2Retimers- DRS-
>                 LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
>                          Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
>                          Compliance De-emphasis: -6dB
>                 LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
>                          EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
>                          Retimer- 2Retimers- CrosslinkRes: unsupported
>         Capabilities: [d0] Vital Product Data
>                 Not readable
>         Capabilities: [100 v2] Advanced Error Reporting
>                 UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>                 UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>                 UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>                 CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
>                 CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
>                 AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
>                         MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
>                 HeaderLog: 00000000 00000000 00000000 00000000
>         Capabilities: [140 v1] Device Serial Number 00-00-00-00-00-00-00-00
>         Capabilities: [150 v1] Power Budgeting <?>
>         Capabilities: [160 v1] Latency Tolerance Reporting
>                 Max snoop latency: 71680ns
>                 Max no snoop latency: 71680ns
>         Kernel driver in use: ahci
> 
> 
>  > And could you please test with the following applied to verify the
>  > assumption? It disables VPD access for this device.
>  > 
>  > ---
>  >  drivers/pci/vpd.c | 1 +
>  >  1 file changed, 1 insertion(+)
>  > 
>  > diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
>  > index 517789205..fc92e880e 100644
>  > --- a/drivers/pci/vpd.c
>  > +++ b/drivers/pci/vpd.c
>  > @@ -540,6 +540,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, quirk_blacklist_vpd);
>  >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, quirk_blacklist_vpd);
>  >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd);
>  >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
>  > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SAMSUNG, 0xa800, quirk_blacklist_vpd);
>  >  /*
>  >   * The Amazon Annapurna Labs 0x0031 device id is reused for other non Root Port
>  >   * device types, so the quirk is registered for the PCI_CLASS_BRIDGE_PCI class.
> 
> 
> 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

> 
> 	Dave
> 
Heiner

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 20:22       ` Heiner Kallweit
@ 2021-09-13 20:32         ` Dave Jones
  2021-09-13 20:44             ` [Intel-wired-lan] " Heiner Kallweit
  2021-09-13 20:59           ` Linux 5.15-rc1 Heiner Kallweit
  0 siblings, 2 replies; 53+ messages in thread
From: Dave Jones @ 2021-09-13 20:32 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Linus Torvalds, Linux Kernel Mailing List, Bjorn Helgaas, linux-pci

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.


I'll add that to the quirk list and see if that helps.

	Dave

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 20:15     ` Dave Jones
  2021-09-13 20:22       ` Heiner Kallweit
@ 2021-09-13 20:32       ` Heiner Kallweit
  2021-09-13 20:36         ` Linus Torvalds
  2021-09-13 20:41         ` Dave Jones
  1 sibling, 2 replies; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-13 20:32 UTC (permalink / raw)
  To: Dave Jones, Linus Torvalds, Linux Kernel Mailing List,
	Bjorn Helgaas, linux-pci

On 13.09.2021 22:15, Dave Jones wrote:
> On Mon, Sep 13, 2021 at 08:59:49PM +0200, Heiner Kallweit wrote:
>  > On 13.09.2021 16:18, Dave Jones wrote:
>  > > [  186.595296] pci 0000:02:00.0: [144d:a800] type 00 class 0x010601
>  > > [  186.595351] pci 0000:02:00.0: reg 0x24: [mem 0xdfc10000-0xdfc11fff]
>  > > [  186.595361] pci 0000:02:00.0: reg 0x30: [mem 0xdfc00000-0xdfc0ffff pref]
>  > > [  186.595425] pci 0000:02:00.0: PME# supported from D3hot D3cold
>  > > [  186.735107] pci 0000:02:00.0: VPD access failed.  This is likely a firmware bug on this device.  Contact the card vendor for a firmware update
>  > 
>  > Thanks for the report! The stalls may be related to this one. Device is:
>  > 02:00.0 SATA controller: Samsung Electronics Co Ltd XP941 PCIe SSD (rev 01)
>  > 
>  > With an older kernel you may experience the stall when accessing the vpd
>  > attribute of this device in sysfs.
>  > 
>  > Maybe the device indicates VPD capability but doesn't actually support it.
>  > Could you please provide the "lspci -vv" output for this device?
> 
> 02:00.0 SATA controller: Samsung Electronics Co Ltd XP941 PCIe SSD (rev 01) (prog-if 01 [AHCI 1.0])
>         Subsystem: Samsung Electronics Co Ltd XP941 PCIe SSD
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0, Cache Line Size: 64 bytes
>         Interrupt: pin A routed to IRQ 16
>         Region 5: Memory at dfc10000 (32-bit, non-prefetchable) [size=8K]
>         Expansion ROM at dfc00000 [disabled] [size=64K]
>         Capabilities: [40] Power Management version 3
>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [70] Express (v2) Endpoint, MSI 00
>                 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
>                         ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 25.000W
>                 DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
>                         RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
>                         MaxPayload 128 bytes, MaxReadReq 512 bytes
>                 DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
>                 LnkCap: Port #0, Speed 5GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us
>                         ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
>                 LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                 LnkSta: Speed 5GT/s (ok), Width x2 (downgraded)
>                         TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>                 DevCap2: Completion Timeout: Not Supported, TimeoutDis+ NROPrPrP- LTR+
>                          10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
>                          EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
>                          FRS- TPHComp- ExtTPHComp-
>                          AtomicOpsCap: 32bit- 64bit- 128bitCAS-
>                 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ OBFF Disabled,
>                          AtomicOpsCtl: ReqEn-
>                 LnkCap2: Supported Link Speeds: 2.5-5GT/s, Crosslink- Retimer- 2Retimers- DRS-
>                 LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
>                          Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
>                          Compliance De-emphasis: -6dB
>                 LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
>                          EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
>                          Retimer- 2Retimers- CrosslinkRes: unsupported
>         Capabilities: [d0] Vital Product Data
>                 Not readable
>         Capabilities: [100 v2] Advanced Error Reporting
>                 UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>                 UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>                 UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>                 CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
>                 CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
>                 AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
>                         MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
>                 HeaderLog: 00000000 00000000 00000000 00000000
>         Capabilities: [140 v1] Device Serial Number 00-00-00-00-00-00-00-00
>         Capabilities: [150 v1] Power Budgeting <?>
>         Capabilities: [160 v1] Latency Tolerance Reporting
>                 Max snoop latency: 71680ns
>                 Max no snoop latency: 71680ns
>         Kernel driver in use: ahci
> 
> 
>  > And could you please test with the following applied to verify the
>  > assumption? It disables VPD access for this device.
>  > 
>  > ---
>  >  drivers/pci/vpd.c | 1 +
>  >  1 file changed, 1 insertion(+)
>  > 
>  > diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
>  > index 517789205..fc92e880e 100644
>  > --- a/drivers/pci/vpd.c
>  > +++ b/drivers/pci/vpd.c
>  > @@ -540,6 +540,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, quirk_blacklist_vpd);
>  >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, quirk_blacklist_vpd);
>  >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd);
>  >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
>  > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SAMSUNG, 0xa800, quirk_blacklist_vpd);
>  >  /*
>  >   * The Amazon Annapurna Labs 0x0031 device id is reused for other non Root Port
>  >   * device types, so the quirk is registered for the PCI_CLASS_BRIDGE_PCI class.
> 
> 
> 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
> 

OK, so this device is buggy too but not the root cause. After checking again the
stalls happen for VPD access to both ports of the Intel network adapter.

01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

I modified the test patch accordingly, could you please test again?

---
 drivers/pci/vpd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
index 517789205..fc92e880e 100644
--- a/drivers/pci/vpd.c
+++ b/drivers/pci/vpd.c
@@ -540,6 +540,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, quirk_blacklist_vpd);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, quirk_blacklist_vpd);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x10fb, quirk_blacklist_vpd);
 /*
  * The Amazon Annapurna Labs 0x0031 device id is reused for other non Root Port
  * device types, so the quirk is registered for the PCI_CLASS_BRIDGE_PCI class.
-- 
2.33.0


^ permalink raw reply related	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 20:32       ` Heiner Kallweit
@ 2021-09-13 20:36         ` Linus Torvalds
  2021-09-13 20:41         ` Dave Jones
  1 sibling, 0 replies; 53+ messages in thread
From: Linus Torvalds @ 2021-09-13 20:36 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Dave Jones, Linux Kernel Mailing List, Bjorn Helgaas, linux-pci

On Mon, Sep 13, 2021 at 1:33 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> OK, so this device is buggy too but not the root cause. After checking again the
> stalls happen for VPD access to both ports of the Intel network adapter.

I really don't want to add quirks like this.

If this happens to a major manufacturer (whoe _defined_ the PCI
standard, for chrissake), then this is not something where we want a
quirk to avoid a boot-time delay.

That commit needs to be reverted. If reverting it is hard, then we
need to revert everything it depends on.

              Linus

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 20:32       ` Heiner Kallweit
  2021-09-13 20:36         ` Linus Torvalds
@ 2021-09-13 20:41         ` Dave Jones
  1 sibling, 0 replies; 53+ messages in thread
From: Dave Jones @ 2021-09-13 20:41 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Linus Torvalds, Linux Kernel Mailing List, Bjorn Helgaas, linux-pci

On Mon, Sep 13, 2021 at 10:32:56PM +0200, Heiner Kallweit wrote:

 > > [  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
 > > 
 > 
 > OK, so this device is buggy too but not the root cause. After checking again the
 > stalls happen for VPD access to both ports of the Intel network adapter.
 > 
 > 01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
 > 01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
 > 
 > I modified the test patch accordingly, could you please test again?

That does avoid the stall.

	Dave

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-13 20:32         ` Dave Jones
@ 2021-09-13 20:44             ` Heiner Kallweit
  2021-09-13 20:59           ` Linux 5.15-rc1 Heiner Kallweit
  1 sibling, 0 replies; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-13 20:44 UTC (permalink / raw)
  To: Jesse Brandeburg, Tony Nguyen
  Cc: linux-pci, Linus Torvalds, Linux Kernel Mailing List,
	Bjorn Helgaas, Dave Jones, intel-wired-lan

On 13.09.2021 22:32, Dave Jones wrote:

+ Jesse and Tony as Intel NIC maintainers

> 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.
> 

When searching I found the same symptom of invalid VPD data for 82599EB.
Do these adapters have non-VPD data in VPD address space? Or is the actual
VPD data at another offset than 0? I know that few Chelsio devices have
such a non-standard VPD structure.

> 
> I'll add that to the quirk list and see if that helps.
> 
> 	Dave
> 
Heiner

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-13 20:44             ` Heiner Kallweit
  0 siblings, 0 replies; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-13 20:44 UTC (permalink / raw)
  To: intel-wired-lan

On 13.09.2021 22:32, Dave Jones wrote:

+ Jesse and Tony as Intel NIC maintainers

> 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.
> 

When searching I found the same symptom of invalid VPD data for 82599EB.
Do these adapters have non-VPD data in VPD address space? Or is the actual
VPD data at another offset than 0? I know that few Chelsio devices have
such a non-standard VPD structure.

> 
> I'll add that to the quirk list and see if that helps.
> 
> 	Dave
> 
Heiner

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 20:32         ` Dave Jones
  2021-09-13 20:44             ` [Intel-wired-lan] " Heiner Kallweit
@ 2021-09-13 20:59           ` Heiner Kallweit
  2021-09-13 23:35             ` Bjorn Helgaas
  1 sibling, 1 reply; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-13 20:59 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: linux-pci

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
> 


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-13 20:44             ` [Intel-wired-lan] " Heiner Kallweit
@ 2021-09-13 23:32               ` Hisashi T Fujinaka
  -1 siblings, 0 replies; 53+ messages in thread
From: Hisashi T Fujinaka @ 2021-09-13 23:32 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Jesse Brandeburg, Tony Nguyen, Dave Jones, linux-pci,
	Linux Kernel Mailing List, intel-wired-lan, Bjorn Helgaas,
	Linus Torvalds, todd.fujinaka

On Mon, 13 Sep 2021, Heiner Kallweit wrote:

> On 13.09.2021 22:32, Dave Jones wrote:
>
> + Jesse and Tony as Intel NIC maintainers
>
>> 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.
>>
>
> When searching I found the same symptom of invalid VPD data for 82599EB.
> Do these adapters have non-VPD data in VPD address space? Or is the actual
> VPD data at another offset than 0? I know that few Chelsio devices have
> such a non-standard VPD structure.
>
>>
>> I'll add that to the quirk list and see if that helps.
>>
>> 	Dave
>>
> Heiner

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@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@intel.com)

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-13 23:32               ` Hisashi T Fujinaka
  0 siblings, 0 replies; 53+ messages in thread
From: Hisashi T Fujinaka @ 2021-09-13 23:32 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, 13 Sep 2021, Heiner Kallweit wrote:

> On 13.09.2021 22:32, Dave Jones wrote:
>
> + Jesse and Tony as Intel NIC maintainers
>
>> 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.
>>
>
> When searching I found the same symptom of invalid VPD data for 82599EB.
> Do these adapters have non-VPD data in VPD address space? Or is the actual
> VPD data at another offset than 0? I know that few Chelsio devices have
> such a non-standard VPD structure.
>
>>
>> I'll add that to the quirk list and see if that helps.
>>
>> 	Dave
>>
> Heiner

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)

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 20:59           ` Linux 5.15-rc1 Heiner Kallweit
@ 2021-09-13 23:35             ` Bjorn Helgaas
  0 siblings, 0 replies; 53+ messages in thread
From: Bjorn Helgaas @ 2021-09-13 23:35 UTC (permalink / raw)
  To: Heiner Kallweit; +Cc: Bjorn Helgaas, linux-pci

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

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 14:18 ` Dave Jones
  2021-09-13 18:59   ` Heiner Kallweit
@ 2021-09-13 23:46   ` Bjorn Helgaas
  2021-09-14  0:39     ` Dave Jones
  2021-09-14  6:21     ` Heiner Kallweit
  1 sibling, 2 replies; 53+ messages in thread
From: Bjorn Helgaas @ 2021-09-13 23:46 UTC (permalink / raw)
  To: Dave Jones, Linus Torvalds, Heiner Kallweit; +Cc: linux-kernel, linux-pci

On Mon, Sep 13, 2021 at 10:18:18AM -0400, Dave Jones wrote:
> On Sun, Sep 12, 2021 at 04:58:27PM -0700, Linus Torvalds wrote:
>  > So 5.15 isn't shaping up to be a particularly large release, at least
>  > in number of commits. At only just over 10k non-merge commits, this is
>  > in fact the smallest rc1 we have had in the 5.x series. We're usually
>  > hovering in the 12-14k commit range.
> 
> This release takes over two minutes longer to boot on one my
> machines than 5.14.  The time just seems to be unaccounted for, even
> with initcall_debug

> ...
> [    2.194093] pci 0000:01:00.0: calling  quirk_f0_vpd_link+0x0/0x60 @ 1
> [    2.194097] pci 0000:01:00.0: quirk_f0_vpd_link+0x0/0x60 took 0 usecs
> [    2.194100] pci 0000:01:00.0: [8086:10fb] type 00 class 0x020000
> [    2.194109] pci 0000:01:00.0: reg 0x10: [mem 0xd0080000-0xd00fffff 64bit pref]
> [    2.194113] pci 0000:01:00.0: reg 0x18: [io  0xe020-0xe03f]
> [    2.194121] pci 0000:01:00.0: reg 0x20: [mem 0xd0104000-0xd0107fff 64bit pref]
> [    2.194126] pci 0000:01:00.0: reg 0x30: [mem 0xdfd80000-0xdfdfffff pref]
> [    2.194136] pci 0000:01:00.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
> [    2.194139] pci 0000:01:00.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
> [    2.194164] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
> 
> * stall here for 86 seconds *
> 
> [   88.675114] pci 0000:01:00.0: reg 0x184: [mem 0x00000000-0x00003fff 64bit pref]
> ...


> 7bac54497c3e3b2ca37b7043f1fa78586540f10e is the first bad commit
> commit 7bac54497c3e3b2ca37b7043f1fa78586540f10e
> Author: Heiner Kallweit <hkallweit1@gmail.com>
> Date:   Sun Aug 8 19:22:52 2021 +0200
> 
>     PCI/VPD: Determine VPD size in pci_vpd_init()
> 
>     Determine VPD size in pci_vpd_init().
> 
>     Quirks set dev->vpd.len to a non-zero value, so they cause us to skip the
>     dynamic size calculation.  Prerequisite is that we move the quirks from
>     FINAL to HEADER so they are run before pci_vpd_init().
> 
>     Link: https://lore.kernel.org/r/cc4a6538-557a-294d-4f94-e6d1d3c91589@gmail.com
>     Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>     Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> 
> 
> Which unfortunately doesn't revert cleanly I can't test it reverted in
> isolation.
> 
> My guess is there's something quirky about the PCI bus on this machine
> that causes stalls until we hit timeout, but I'm not sure where to begin
> debugging this.

Sorry for the inconvenience of this, and thank you very much for doing
the bisection to track it down.

We *could* revert 7bac54497c3e, but it'd be messy because a bunch of
follow-up stuff depends on it.

I propose something like the patch below.  Would you mind trying it
out?


commit 4ede9949b93c ("PCI/VPD: Defer VPD sizing until first access")
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Mon Sep 13 16:13:26 2021 -0500

    PCI/VPD: Defer VPD sizing until first access
    
    7bac54497c3e ("PCI/VPD: Determine VPD size in pci_vpd_init()") reads VPD at
    enumeration-time to find the size.  But this is quite slow, and we don't
    need the size until we actually need data from VPD.  Dave reported a boot
    slowdown of more than two minutes [1].
    
    Defer the VPD sizing until a driver or the user requests information from
    VPD.  If devices are quirked because VPD is known not to work, clear the
    vpd.cap pointer so we don't access it at all.
    
    [1] https://lore.kernel.org/r/20210913141818.GA27911@codemonkey.org.uk/
    Fixes: 7bac54497c3e ("PCI/VPD: Determine VPD size in pci_vpd_init()")
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
index 25557b272a4f..ca823ceee10c 100644
--- a/drivers/pci/vpd.c
+++ b/drivers/pci/vpd.c
@@ -46,13 +46,12 @@ static struct pci_dev *pci_get_func0_dev(struct pci_dev *dev)
 }
 
 #define PCI_VPD_MAX_SIZE	(PCI_VPD_ADDR_MASK + 1)
-#define PCI_VPD_SZ_INVALID	UINT_MAX
 
 /**
  * pci_vpd_size - determine actual size of Vital Product Data
  * @dev:	pci device struct
  */
-static size_t pci_vpd_size(struct pci_dev *dev)
+static void pci_vpd_size(struct pci_dev *dev)
 {
 	size_t off = 0, size;
 	unsigned char tag, header[1+2];	/* 1 byte tag, 2 bytes length */
@@ -71,7 +70,7 @@ static size_t pci_vpd_size(struct pci_dev *dev)
 			if (pci_read_vpd(dev, off + 1, 2, &header[1]) != 2) {
 				pci_warn(dev, "failed VPD read at offset %zu\n",
 					 off + 1);
-				return off ?: PCI_VPD_SZ_INVALID;
+				goto finish;
 			}
 			size = pci_vpd_lrdt_size(header);
 			if (off + size > PCI_VPD_MAX_SIZE)
@@ -87,16 +86,19 @@ static size_t pci_vpd_size(struct pci_dev *dev)
 
 			off += PCI_VPD_SRDT_TAG_SIZE + size;
 			if (tag == PCI_VPD_STIN_END)	/* End tag descriptor */
-				return off;
+				goto finish;
 		}
 	}
-	return off;
+	goto finish;
 
 error:
 	pci_info(dev, "invalid VPD tag %#04x (size %zu) at offset %zu%s\n",
 		 header[0], size, off, off == 0 ?
 		 "; assume missing optional EEPROM" : "");
-	return off ?: PCI_VPD_SZ_INVALID;
+finish:
+	dev->vpd.len = off;
+	if (off == 0)
+		dev->vpd.cap = 0;		/* No VPD at all */
 }
 
 /*
@@ -145,9 +147,6 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
 	loff_t end = pos + count;
 	u8 *buf = arg;
 
-	if (!vpd->cap)
-		return -ENODEV;
-
 	if (pos < 0)
 		return -EINVAL;
 
@@ -206,9 +205,6 @@ static ssize_t pci_vpd_write(struct pci_dev *dev, loff_t pos, size_t count,
 	loff_t end = pos + count;
 	int ret = 0;
 
-	if (!vpd->cap)
-		return -ENODEV;
-
 	if (pos < 0 || (pos & 3) || (count & 3))
 		return -EINVAL;
 
@@ -244,12 +240,6 @@ void pci_vpd_init(struct pci_dev *dev)
 {
 	dev->vpd.cap = pci_find_capability(dev, PCI_CAP_ID_VPD);
 	mutex_init(&dev->vpd.lock);
-
-	if (!dev->vpd.len)
-		dev->vpd.len = pci_vpd_size(dev);
-
-	if (dev->vpd.len == PCI_VPD_SZ_INVALID)
-		dev->vpd.cap = 0;
 }
 
 static ssize_t vpd_read(struct file *filp, struct kobject *kobj,
@@ -294,25 +284,29 @@ const struct attribute_group pci_dev_vpd_attr_group = {
 
 void *pci_vpd_alloc(struct pci_dev *dev, unsigned int *size)
 {
-	unsigned int len = dev->vpd.len;
+	struct pci_vpd *vpd = &dev->vpd;
+	unsigned int len;
 	void *buf;
 	int cnt;
 
-	if (!dev->vpd.cap)
+	if (!vpd->cap)
 		return ERR_PTR(-ENODEV);
 
 	buf = kmalloc(len, GFP_KERNEL);
 	if (!buf)
 		return ERR_PTR(-ENOMEM);
 
-	cnt = pci_read_vpd(dev, 0, len, buf);
+	if (vpd->len == 0)
+		pci_vpd_size(dev);
+
+	cnt = pci_read_vpd(dev, 0, vpd->len, buf);
 	if (cnt != len) {
 		kfree(buf);
 		return ERR_PTR(-EIO);
 	}
 
 	if (size)
-		*size = len;
+		*size = vpd->len;
 
 	return buf;
 }
@@ -374,6 +368,7 @@ static int pci_vpd_find_info_keyword(const u8 *buf, unsigned int off,
  */
 ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos, size_t count, void *buf)
 {
+	struct pci_vpd *vpd;
 	ssize_t ret;
 
 	if (dev->dev_flags & PCI_DEV_FLAGS_VPD_REF_F0) {
@@ -381,11 +376,27 @@ ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos, size_t count, void *buf)
 		if (!dev)
 			return -ENODEV;
 
+		vpd = &dev->vpd;
+		if (!vpd->cap) {
+			pci_dev_put(dev);
+			return -ENODEV;
+		}
+
+		if (vpd->len == 0)
+			pci_vpd_size(dev);
+
 		ret = pci_vpd_read(dev, pos, count, buf);
 		pci_dev_put(dev);
 		return ret;
 	}
 
+	vpd = &dev->vpd;
+	if (!vpd->cap)
+		return -ENODEV;
+
+	if (vpd->len == 0)
+		pci_vpd_size(dev);
+
 	return pci_vpd_read(dev, pos, count, buf);
 }
 EXPORT_SYMBOL(pci_read_vpd);
@@ -399,6 +410,7 @@ EXPORT_SYMBOL(pci_read_vpd);
  */
 ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const void *buf)
 {
+	struct pci_vpd *vpd;
 	ssize_t ret;
 
 	if (dev->dev_flags & PCI_DEV_FLAGS_VPD_REF_F0) {
@@ -406,11 +418,26 @@ ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const void
 		if (!dev)
 			return -ENODEV;
 
+		vpd = &dev->vpd;
+		if (!vpd->cap) {
+			pci_dev_put(dev);
+			return -ENODEV;
+		}
+
+		if (vpd->len == 0)
+			pci_vpd_size(dev);
+
 		ret = pci_vpd_write(dev, pos, count, buf);
 		pci_dev_put(dev);
 		return ret;
 	}
 
+	if (!vpd->cap)
+		return -ENODEV;
+
+	if (vpd->len == 0)
+		pci_vpd_size(dev);
+
 	return pci_vpd_write(dev, pos, count, buf);
 }
 EXPORT_SYMBOL(pci_write_vpd);
@@ -500,27 +527,27 @@ DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
  */
 static void quirk_blacklist_vpd(struct pci_dev *dev)
 {
-	dev->vpd.len = PCI_VPD_SZ_INVALID;
+	dev->vpd.cap = 0;
 	pci_warn(dev, FW_BUG "disabling VPD access (can't determine size of non-standard VPD format)\n");
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0060, quirk_blacklist_vpd);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x007c, quirk_blacklist_vpd);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0413, quirk_blacklist_vpd);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0078, quirk_blacklist_vpd);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0079, quirk_blacklist_vpd);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0073, quirk_blacklist_vpd);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0071, quirk_blacklist_vpd);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005b, quirk_blacklist_vpd);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, quirk_blacklist_vpd);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, quirk_blacklist_vpd);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
 /*
  * The Amazon Annapurna Labs 0x0031 device id is reused for other non Root Port
  * device types, so the quirk is registered for the PCI_CLASS_BRIDGE_PCI class.
  */
-DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031,
-			       PCI_CLASS_BRIDGE_PCI, 8, quirk_blacklist_vpd);
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031,
+			      PCI_CLASS_BRIDGE_PCI, 8, quirk_blacklist_vpd);
 
 static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
 {
@@ -545,7 +572,7 @@ static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
 		dev->vpd.len = 2048;
 }
 
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
-			 quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
+			quirk_chelsio_extend_vpd);
 
 #endif

^ permalink raw reply related	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 23:46   ` Bjorn Helgaas
@ 2021-09-14  0:39     ` Dave Jones
  2021-09-14  6:21     ` Heiner Kallweit
  1 sibling, 0 replies; 53+ messages in thread
From: Dave Jones @ 2021-09-14  0:39 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: Linus Torvalds, Heiner Kallweit, linux-kernel, linux-pci

On Mon, Sep 13, 2021 at 06:46:08PM -0500, Bjorn Helgaas wrote:
 > On Mon, Sep 13, 2021 at 10:18:18AM -0400, Dave Jones wrote:
 > > On Sun, Sep 12, 2021 at 04:58:27PM -0700, Linus Torvalds wrote:
 > >  > So 5.15 isn't shaping up to be a particularly large release, at least
 > >  > in number of commits. At only just over 10k non-merge commits, this is
 > >  > in fact the smallest rc1 we have had in the 5.x series. We're usually
 > >  > hovering in the 12-14k commit range.
 > > 
 > > This release takes over two minutes longer to boot on one my
 > > machines than 5.14.  The time just seems to be unaccounted for, even
 > > with initcall_debug
 > 
 > Sorry for the inconvenience of this, and thank you very much for doing
 > the bisection to track it down.
 > 
 > We *could* revert 7bac54497c3e, but it'd be messy because a bunch of
 > follow-up stuff depends on it.
 > 
 > I propose something like the patch below.  Would you mind trying it
 > out?

This also fixes the problem for me.

	Dave

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-13 23:32               ` Hisashi T Fujinaka
@ 2021-09-14  5:51                 ` Heiner Kallweit
  -1 siblings, 0 replies; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-14  5:51 UTC (permalink / raw)
  To: Dave Jones
  Cc: Jesse Brandeburg, Tony Nguyen, linux-pci,
	Linux Kernel Mailing List, intel-wired-lan, Bjorn Helgaas,
	todd.fujinaka, Hisashi T Fujinaka

On 14.09.2021 01:32, Hisashi T Fujinaka wrote:
> On Mon, 13 Sep 2021, Heiner Kallweit wrote:
> 
>> On 13.09.2021 22:32, Dave Jones wrote:
>>
>> + Jesse and Tony as Intel NIC maintainers
>>
>>> 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.
>>>
>>
>> When searching I found the same symptom of invalid VPD data for 82599EB.
>> Do these adapters have non-VPD data in VPD address space? Or is the actual
>> VPD data at another offset than 0? I know that few Chelsio devices have
>> such a non-standard VPD structure.
>>
>>>
>>> I'll add that to the quirk list and see if that helps.
>>>
>>>     Dave
>>>
>> Heiner
> 
> 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@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@intel.com)

Thanks for the prompt reply. Dave, could you please provide the requested
information?

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-14  5:51                 ` Heiner Kallweit
  0 siblings, 0 replies; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-14  5:51 UTC (permalink / raw)
  To: intel-wired-lan

On 14.09.2021 01:32, Hisashi T Fujinaka wrote:
> On Mon, 13 Sep 2021, Heiner Kallweit wrote:
> 
>> On 13.09.2021 22:32, Dave Jones wrote:
>>
>> + Jesse and Tony as Intel NIC maintainers
>>
>>> 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.
>>>
>>
>> When searching I found the same symptom of invalid VPD data for 82599EB.
>> Do these adapters have non-VPD data in VPD address space? Or is the actual
>> VPD data at another offset than 0? I know that few Chelsio devices have
>> such a non-standard VPD structure.
>>
>>>
>>> I'll add that to the quirk list and see if that helps.
>>>
>>> ????Dave
>>>
>> Heiner
> 
> 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?

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13 23:46   ` Bjorn Helgaas
  2021-09-14  0:39     ` Dave Jones
@ 2021-09-14  6:21     ` Heiner Kallweit
  2021-09-14 11:26       ` Bjorn Helgaas
  1 sibling, 1 reply; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-14  6:21 UTC (permalink / raw)
  To: Bjorn Helgaas, Dave Jones, Linus Torvalds; +Cc: linux-kernel, linux-pci

On 14.09.2021 01:46, Bjorn Helgaas wrote:
> On Mon, Sep 13, 2021 at 10:18:18AM -0400, Dave Jones wrote:
>> On Sun, Sep 12, 2021 at 04:58:27PM -0700, Linus Torvalds wrote:
>>  > So 5.15 isn't shaping up to be a particularly large release, at least
>>  > in number of commits. At only just over 10k non-merge commits, this is
>>  > in fact the smallest rc1 we have had in the 5.x series. We're usually
>>  > hovering in the 12-14k commit range.
>>
>> This release takes over two minutes longer to boot on one my
>> machines than 5.14.  The time just seems to be unaccounted for, even
>> with initcall_debug
> 
>> ...
>> [    2.194093] pci 0000:01:00.0: calling  quirk_f0_vpd_link+0x0/0x60 @ 1
>> [    2.194097] pci 0000:01:00.0: quirk_f0_vpd_link+0x0/0x60 took 0 usecs
>> [    2.194100] pci 0000:01:00.0: [8086:10fb] type 00 class 0x020000
>> [    2.194109] pci 0000:01:00.0: reg 0x10: [mem 0xd0080000-0xd00fffff 64bit pref]
>> [    2.194113] pci 0000:01:00.0: reg 0x18: [io  0xe020-0xe03f]
>> [    2.194121] pci 0000:01:00.0: reg 0x20: [mem 0xd0104000-0xd0107fff 64bit pref]
>> [    2.194126] pci 0000:01:00.0: reg 0x30: [mem 0xdfd80000-0xdfdfffff pref]
>> [    2.194136] pci 0000:01:00.0: calling  quirk_igfx_skip_te_disable+0x0/0x50 @ 1
>> [    2.194139] pci 0000:01:00.0: quirk_igfx_skip_te_disable+0x0/0x50 took 0 usecs
>> [    2.194164] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
>>
>> * stall here for 86 seconds *
>>
>> [   88.675114] pci 0000:01:00.0: reg 0x184: [mem 0x00000000-0x00003fff 64bit pref]
>> ...
> 
> 
>> 7bac54497c3e3b2ca37b7043f1fa78586540f10e is the first bad commit
>> commit 7bac54497c3e3b2ca37b7043f1fa78586540f10e
>> Author: Heiner Kallweit <hkallweit1@gmail.com>
>> Date:   Sun Aug 8 19:22:52 2021 +0200
>>
>>     PCI/VPD: Determine VPD size in pci_vpd_init()
>>
>>     Determine VPD size in pci_vpd_init().
>>
>>     Quirks set dev->vpd.len to a non-zero value, so they cause us to skip the
>>     dynamic size calculation.  Prerequisite is that we move the quirks from
>>     FINAL to HEADER so they are run before pci_vpd_init().
>>
>>     Link: https://lore.kernel.org/r/cc4a6538-557a-294d-4f94-e6d1d3c91589@gmail.com
>>     Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>     Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>
>>
>> Which unfortunately doesn't revert cleanly I can't test it reverted in
>> isolation.
>>
>> My guess is there's something quirky about the PCI bus on this machine
>> that causes stalls until we hit timeout, but I'm not sure where to begin
>> debugging this.
> 
> Sorry for the inconvenience of this, and thank you very much for doing
> the bisection to track it down.
> 
> We *could* revert 7bac54497c3e, but it'd be messy because a bunch of
> follow-up stuff depends on it.
> 
> I propose something like the patch below.  Would you mind trying it
> out?
> 
> 
> commit 4ede9949b93c ("PCI/VPD: Defer VPD sizing until first access")
> Author: Bjorn Helgaas <bhelgaas@google.com>
> Date:   Mon Sep 13 16:13:26 2021 -0500
> 
>     PCI/VPD: Defer VPD sizing until first access
>     
>     7bac54497c3e ("PCI/VPD: Determine VPD size in pci_vpd_init()") reads VPD at
>     enumeration-time to find the size.  But this is quite slow, and we don't
>     need the size until we actually need data from VPD.  Dave reported a boot
>     slowdown of more than two minutes [1].
>     
>     Defer the VPD sizing until a driver or the user requests information from
>     VPD.  If devices are quirked because VPD is known not to work, clear the
>     vpd.cap pointer so we don't access it at all.
>     
>     [1] https://lore.kernel.org/r/20210913141818.GA27911@codemonkey.org.uk/
>     Fixes: 7bac54497c3e ("PCI/VPD: Determine VPD size in pci_vpd_init()")
>     Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> 
> diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
> index 25557b272a4f..ca823ceee10c 100644
> --- a/drivers/pci/vpd.c
> +++ b/drivers/pci/vpd.c
> @@ -46,13 +46,12 @@ static struct pci_dev *pci_get_func0_dev(struct pci_dev *dev)
>  }
>  
>  #define PCI_VPD_MAX_SIZE	(PCI_VPD_ADDR_MASK + 1)
> -#define PCI_VPD_SZ_INVALID	UINT_MAX
>  
>  /**
>   * pci_vpd_size - determine actual size of Vital Product Data
>   * @dev:	pci device struct
>   */
> -static size_t pci_vpd_size(struct pci_dev *dev)
> +static void pci_vpd_size(struct pci_dev *dev)
>  {
>  	size_t off = 0, size;
>  	unsigned char tag, header[1+2];	/* 1 byte tag, 2 bytes length */
> @@ -71,7 +70,7 @@ static size_t pci_vpd_size(struct pci_dev *dev)
>  			if (pci_read_vpd(dev, off + 1, 2, &header[1]) != 2) {
>  				pci_warn(dev, "failed VPD read at offset %zu\n",
>  					 off + 1);
> -				return off ?: PCI_VPD_SZ_INVALID;
> +				goto finish;
>  			}
>  			size = pci_vpd_lrdt_size(header);
>  			if (off + size > PCI_VPD_MAX_SIZE)
> @@ -87,16 +86,19 @@ static size_t pci_vpd_size(struct pci_dev *dev)
>  
>  			off += PCI_VPD_SRDT_TAG_SIZE + size;
>  			if (tag == PCI_VPD_STIN_END)	/* End tag descriptor */
> -				return off;
> +				goto finish;
>  		}
>  	}
> -	return off;
> +	goto finish;
>  
>  error:
>  	pci_info(dev, "invalid VPD tag %#04x (size %zu) at offset %zu%s\n",
>  		 header[0], size, off, off == 0 ?
>  		 "; assume missing optional EEPROM" : "");
> -	return off ?: PCI_VPD_SZ_INVALID;
> +finish:
> +	dev->vpd.len = off;
> +	if (off == 0)
> +		dev->vpd.cap = 0;		/* No VPD at all */
>  }
>  
>  /*
> @@ -145,9 +147,6 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
>  	loff_t end = pos + count;
>  	u8 *buf = arg;
>  
> -	if (!vpd->cap)
> -		return -ENODEV;
> -
>  	if (pos < 0)
>  		return -EINVAL;
>  
> @@ -206,9 +205,6 @@ static ssize_t pci_vpd_write(struct pci_dev *dev, loff_t pos, size_t count,
>  	loff_t end = pos + count;
>  	int ret = 0;
>  
> -	if (!vpd->cap)
> -		return -ENODEV;
> -
>  	if (pos < 0 || (pos & 3) || (count & 3))
>  		return -EINVAL;
>  
> @@ -244,12 +240,6 @@ void pci_vpd_init(struct pci_dev *dev)
>  {
>  	dev->vpd.cap = pci_find_capability(dev, PCI_CAP_ID_VPD);
>  	mutex_init(&dev->vpd.lock);
> -
> -	if (!dev->vpd.len)
> -		dev->vpd.len = pci_vpd_size(dev);
> -
> -	if (dev->vpd.len == PCI_VPD_SZ_INVALID)
> -		dev->vpd.cap = 0;
>  }
>  
>  static ssize_t vpd_read(struct file *filp, struct kobject *kobj,
> @@ -294,25 +284,29 @@ const struct attribute_group pci_dev_vpd_attr_group = {
>  
>  void *pci_vpd_alloc(struct pci_dev *dev, unsigned int *size)
>  {
> -	unsigned int len = dev->vpd.len;
> +	struct pci_vpd *vpd = &dev->vpd;
> +	unsigned int len;
>  	void *buf;
>  	int cnt;
>  
> -	if (!dev->vpd.cap)
> +	if (!vpd->cap)
>  		return ERR_PTR(-ENODEV);
>  
>  	buf = kmalloc(len, GFP_KERNEL);
>  	if (!buf)
>  		return ERR_PTR(-ENOMEM);
>  
> -	cnt = pci_read_vpd(dev, 0, len, buf);
> +	if (vpd->len == 0)
> +		pci_vpd_size(dev);
> +
> +	cnt = pci_read_vpd(dev, 0, vpd->len, buf);
>  	if (cnt != len) {
>  		kfree(buf);
>  		return ERR_PTR(-EIO);
>  	}
>  
>  	if (size)
> -		*size = len;
> +		*size = vpd->len;
>  
>  	return buf;
>  }
> @@ -374,6 +368,7 @@ static int pci_vpd_find_info_keyword(const u8 *buf, unsigned int off,
>   */
>  ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos, size_t count, void *buf)
>  {
> +	struct pci_vpd *vpd;
>  	ssize_t ret;
>  
>  	if (dev->dev_flags & PCI_DEV_FLAGS_VPD_REF_F0) {
> @@ -381,11 +376,27 @@ ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos, size_t count, void *buf)
>  		if (!dev)
>  			return -ENODEV;
>  
> +		vpd = &dev->vpd;
> +		if (!vpd->cap) {
> +			pci_dev_put(dev);
> +			return -ENODEV;
> +		}
> +
> +		if (vpd->len == 0)
> +			pci_vpd_size(dev);
> +
>  		ret = pci_vpd_read(dev, pos, count, buf);
>  		pci_dev_put(dev);
>  		return ret;
>  	}
>  
> +	vpd = &dev->vpd;
> +	if (!vpd->cap)
> +		return -ENODEV;
> +
> +	if (vpd->len == 0)
> +		pci_vpd_size(dev);
> +
>  	return pci_vpd_read(dev, pos, count, buf);
>  }
>  EXPORT_SYMBOL(pci_read_vpd);
> @@ -399,6 +410,7 @@ EXPORT_SYMBOL(pci_read_vpd);
>   */
>  ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const void *buf)
>  {
> +	struct pci_vpd *vpd;
>  	ssize_t ret;
>  
>  	if (dev->dev_flags & PCI_DEV_FLAGS_VPD_REF_F0) {
> @@ -406,11 +418,26 @@ ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const void
>  		if (!dev)
>  			return -ENODEV;
>  
> +		vpd = &dev->vpd;
> +		if (!vpd->cap) {
> +			pci_dev_put(dev);
> +			return -ENODEV;
> +		}
> +
> +		if (vpd->len == 0)
> +			pci_vpd_size(dev);
> +
>  		ret = pci_vpd_write(dev, pos, count, buf);
>  		pci_dev_put(dev);
>  		return ret;
>  	}
>  
> +	if (!vpd->cap)
> +		return -ENODEV;
> +
> +	if (vpd->len == 0)
> +		pci_vpd_size(dev);
> +
>  	return pci_vpd_write(dev, pos, count, buf);
>  }
>  EXPORT_SYMBOL(pci_write_vpd);
> @@ -500,27 +527,27 @@ DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
>   */
>  static void quirk_blacklist_vpd(struct pci_dev *dev)
>  {
> -	dev->vpd.len = PCI_VPD_SZ_INVALID;
> +	dev->vpd.cap = 0;
>  	pci_warn(dev, FW_BUG "disabling VPD access (can't determine size of non-standard VPD format)\n");
>  }
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0060, quirk_blacklist_vpd);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x007c, quirk_blacklist_vpd);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0413, quirk_blacklist_vpd);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0078, quirk_blacklist_vpd);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0079, quirk_blacklist_vpd);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0073, quirk_blacklist_vpd);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x0071, quirk_blacklist_vpd);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005b, quirk_blacklist_vpd);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, quirk_blacklist_vpd);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, quirk_blacklist_vpd);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
>  /*

Leaving the quirks in FIXUP_HEADER stage would have the advantage that for
blacklisted devices the vpd sysfs attribute isn't visibale. The needed
changes to the patch are minimal.

>   * The Amazon Annapurna Labs 0x0031 device id is reused for other non Root Port
>   * device types, so the quirk is registered for the PCI_CLASS_BRIDGE_PCI class.
>   */
> -DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031,
> -			       PCI_CLASS_BRIDGE_PCI, 8, quirk_blacklist_vpd);
> +DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031,
> +			      PCI_CLASS_BRIDGE_PCI, 8, quirk_blacklist_vpd);
>  
>  static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
>  {
> @@ -545,7 +572,7 @@ static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
>  		dev->vpd.len = 2048;
>  }
>  
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> -			 quirk_chelsio_extend_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> +			quirk_chelsio_extend_vpd);
>  
>  #endif
> 


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-14  6:21     ` Heiner Kallweit
@ 2021-09-14 11:26       ` Bjorn Helgaas
  2021-09-14 17:07         ` Heiner Kallweit
  0 siblings, 1 reply; 53+ messages in thread
From: Bjorn Helgaas @ 2021-09-14 11:26 UTC (permalink / raw)
  To: Heiner Kallweit; +Cc: Dave Jones, Linus Torvalds, linux-kernel, linux-pci

On Tue, Sep 14, 2021 at 08:21:46AM +0200, Heiner Kallweit wrote:
> On 14.09.2021 01:46, Bjorn Helgaas wrote:

> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
> >  /*
> 
> Leaving the quirks in FIXUP_HEADER stage would have the advantage that for
> blacklisted devices the vpd sysfs attribute isn't visibale. The needed
> changes to the patch are minimal.

What do you have in mind?  The only thing I can think of would be to
add a "pci_dev.no_vpd" bit.  "vpd.cap == 0" means the device has no
VPD, and "vpd.len == 0" means we haven't determined the size yet.  All
devices start off with vpd.cap == 0 and vpd.len == 0, so a
FIXUP_HEADER quirk would have to set a sentinel value or some other
bit.

Bjorn

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-14  5:51                 ` Heiner Kallweit
@ 2021-09-14 14:24                   ` Dave Jones
  -1 siblings, 0 replies; 53+ messages in thread
From: Dave Jones @ 2021-09-14 14:24 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Jesse Brandeburg, Tony Nguyen, linux-pci,
	Linux Kernel Mailing List, intel-wired-lan, Bjorn Helgaas,
	todd.fujinaka, Hisashi T Fujinaka

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@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@intel.com)
 > 
 > Thanks for the prompt reply. Dave, could you please provide the requested
 > information?

sent off-list.

	Dave

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-14 14:24                   ` Dave Jones
  0 siblings, 0 replies; 53+ messages in thread
From: Dave Jones @ 2021-09-14 14:24 UTC (permalink / raw)
  To: intel-wired-lan

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

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-14 11:26       ` Bjorn Helgaas
@ 2021-09-14 17:07         ` Heiner Kallweit
  2021-09-14 21:55           ` Bjorn Helgaas
  0 siblings, 1 reply; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-14 17:07 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: Dave Jones, Linus Torvalds, linux-kernel, linux-pci

On 14.09.2021 13:26, Bjorn Helgaas wrote:
> On Tue, Sep 14, 2021 at 08:21:46AM +0200, Heiner Kallweit wrote:
>> On 14.09.2021 01:46, Bjorn Helgaas wrote:
> 
>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
>>>  /*
>>
>> Leaving the quirks in FIXUP_HEADER stage would have the advantage that for
>> blacklisted devices the vpd sysfs attribute isn't visibale. The needed
>> changes to the patch are minimal.
> 
> What do you have in mind?  The only thing I can think of would be to
> add a "pci_dev.no_vpd" bit.  "vpd.cap == 0" means the device has no
> VPD, and "vpd.len == 0" means we haven't determined the size yet.  All
> devices start off with vpd.cap == 0 and vpd.len == 0, so a
> FIXUP_HEADER quirk would have to set a sentinel value or some other
> bit.
> 
> Bjorn
> 

Why not leave vpd.len == PCI_VPD_SZ_INVALID as sentinel?

And one more question: Why do you move the "if (!vpd->cap)" check from
pci_vpd_read() to pci_read_vpd()? At a first glance I see no benefit.

Here comes my version. Your changes to pci_vpd_size() I left as-is.
I tested the positive case and it works as expected.


diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
index 25557b272..04b14c488 100644
--- a/drivers/pci/vpd.c
+++ b/drivers/pci/vpd.c
@@ -52,7 +52,7 @@ static struct pci_dev *pci_get_func0_dev(struct pci_dev *dev)
  * pci_vpd_size - determine actual size of Vital Product Data
  * @dev:	pci device struct
  */
-static size_t pci_vpd_size(struct pci_dev *dev)
+static void pci_vpd_size(struct pci_dev *dev)
 {
 	size_t off = 0, size;
 	unsigned char tag, header[1+2];	/* 1 byte tag, 2 bytes length */
@@ -71,7 +71,7 @@ static size_t pci_vpd_size(struct pci_dev *dev)
 			if (pci_read_vpd(dev, off + 1, 2, &header[1]) != 2) {
 				pci_warn(dev, "failed VPD read at offset %zu\n",
 					 off + 1);
-				return off ?: PCI_VPD_SZ_INVALID;
+				goto finish;
 			}
 			size = pci_vpd_lrdt_size(header);
 			if (off + size > PCI_VPD_MAX_SIZE)
@@ -87,16 +87,19 @@ static size_t pci_vpd_size(struct pci_dev *dev)
 
 			off += PCI_VPD_SRDT_TAG_SIZE + size;
 			if (tag == PCI_VPD_STIN_END)	/* End tag descriptor */
-				return off;
+				goto finish;
 		}
 	}
-	return off;
+	goto finish;
 
 error:
 	pci_info(dev, "invalid VPD tag %#04x (size %zu) at offset %zu%s\n",
 		 header[0], size, off, off == 0 ?
 		 "; assume missing optional EEPROM" : "");
-	return off ?: PCI_VPD_SZ_INVALID;
+finish:
+	dev->vpd.len = off;
+	if (off == 0)
+		dev->vpd.cap = 0;		/* No VPD at all */
 }
 
 /*
@@ -145,6 +148,8 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
 	loff_t end = pos + count;
 	u8 *buf = arg;
 
+	if (vpd->len == 0 && vpd->cap)
+		pci_vpd_size(dev);
 	if (!vpd->cap)
 		return -ENODEV;
 
@@ -206,6 +211,8 @@ static ssize_t pci_vpd_write(struct pci_dev *dev, loff_t pos, size_t count,
 	loff_t end = pos + count;
 	int ret = 0;
 
+	if (vpd->len == 0 && vpd->cap)
+		pci_vpd_size(dev);
 	if (!vpd->cap)
 		return -ENODEV;
 
@@ -245,9 +252,6 @@ void pci_vpd_init(struct pci_dev *dev)
 	dev->vpd.cap = pci_find_capability(dev, PCI_CAP_ID_VPD);
 	mutex_init(&dev->vpd.lock);
 
-	if (!dev->vpd.len)
-		dev->vpd.len = pci_vpd_size(dev);
-
 	if (dev->vpd.len == PCI_VPD_SZ_INVALID)
 		dev->vpd.cap = 0;
 }
@@ -294,25 +298,27 @@ const struct attribute_group pci_dev_vpd_attr_group = {
 
 void *pci_vpd_alloc(struct pci_dev *dev, unsigned int *size)
 {
-	unsigned int len = dev->vpd.len;
+	struct pci_vpd *vpd = &dev->vpd;
 	void *buf;
 	int cnt;
 
-	if (!dev->vpd.cap)
+	if (vpd->len == 0 && vpd->cap)
+		pci_vpd_size(dev);
+	if (!vpd->cap)
 		return ERR_PTR(-ENODEV);
 
-	buf = kmalloc(len, GFP_KERNEL);
+	buf = kmalloc(vpd->len, GFP_KERNEL);
 	if (!buf)
 		return ERR_PTR(-ENOMEM);
 
-	cnt = pci_read_vpd(dev, 0, len, buf);
-	if (cnt != len) {
+	cnt = pci_read_vpd(dev, 0, vpd->len, buf);
+	if (cnt != vpd->len) {
 		kfree(buf);
 		return ERR_PTR(-EIO);
 	}
 
 	if (size)
-		*size = len;
+		*size = vpd->len;
 
 	return buf;
 }
-- 
2.33.0





^ permalink raw reply related	[flat|nested] 53+ messages in thread

* RE: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-14 14:24                   ` Dave Jones
@ 2021-09-14 18:28                     ` Fujinaka, Todd
  -1 siblings, 0 replies; 53+ messages in thread
From: Fujinaka, Todd @ 2021-09-14 18:28 UTC (permalink / raw)
  To: Dave Jones, Heiner Kallweit
  Cc: Brandeburg, Jesse, Nguyen, Anthony L, linux-pci,
	Linux Kernel Mailing List, intel-wired-lan, Bjorn Helgaas,
	Hisashi T Fujinaka

Wow, I'm waiting for the hardware guy to look at this but this is an off-brand 10Gtek NIC from Amazon that just has nonsense data in the VPD as far as I can tell (3's).

I'll let you know if I find out that the critical settings are bad, but I would just ignore any VPD errors.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujinaka@intel.com

-----Original Message-----
From: Dave Jones <davej@codemonkey.org.uk> 
Sent: Tuesday, September 14, 2021 7:24 AM
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; linux-pci@vger.kernel.org; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; intel-wired-lan <intel-wired-lan@lists.osuosl.org>; Bjorn Helgaas <bhelgaas@google.com>; Fujinaka, Todd <todd.fujinaka@intel.com>; Hisashi T Fujinaka <htodd@twofifty.com>
Subject: Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue

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@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@intel.com)  >  > Thanks for the prompt reply. Dave, could you please provide the requested  > information?

sent off-list.

	Dave

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-14 18:28                     ` Fujinaka, Todd
  0 siblings, 0 replies; 53+ messages in thread
From: Fujinaka, Todd @ 2021-09-14 18:28 UTC (permalink / raw)
  To: intel-wired-lan

Wow, I'm waiting for the hardware guy to look at this but this is an off-brand 10Gtek NIC from Amazon that just has nonsense data in the VPD as far as I can tell (3's).

I'll let you know if I find out that the critical settings are bad, but I would just ignore any VPD errors.

Todd Fujinaka
Software Application Engineer
Ethernet Products Group
Intel Corporation
todd.fujinaka at intel.com

-----Original Message-----
From: Dave Jones <davej@codemonkey.org.uk> 
Sent: Tuesday, September 14, 2021 7:24 AM
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; linux-pci at vger.kernel.org; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; intel-wired-lan <intel-wired-lan@lists.osuosl.org>; Bjorn Helgaas <bhelgaas@google.com>; Fujinaka, Todd <todd.fujinaka@intel.com>; Hisashi T Fujinaka <htodd@twofifty.com>
Subject: Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue

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

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-14 14:24                   ` Dave Jones
@ 2021-09-14 20:00                     ` Hisashi T Fujinaka
  -1 siblings, 0 replies; 53+ messages in thread
From: Hisashi T Fujinaka @ 2021-09-14 20:00 UTC (permalink / raw)
  To: Dave Jones
  Cc: Heiner Kallweit, linux-pci, Linux Kernel Mailing List,
	intel-wired-lan, Bjorn Helgaas

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@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@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?

Todd Fujinaka <todd.fujinaka@intel.com>

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-14 20:00                     ` Hisashi T Fujinaka
  0 siblings, 0 replies; 53+ messages in thread
From: Hisashi T Fujinaka @ 2021-09-14 20:00 UTC (permalink / raw)
  To: intel-wired-lan

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?

Todd Fujinaka <todd.fujinaka@intel.com>

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-14 20:00                     ` Hisashi T Fujinaka
@ 2021-09-14 21:51                       ` Heiner Kallweit
  -1 siblings, 0 replies; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-14 21:51 UTC (permalink / raw)
  To: Hisashi T Fujinaka, Dave Jones
  Cc: linux-pci, Linux Kernel Mailing List, intel-wired-lan, Bjorn Helgaas

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@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@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.

> Todd Fujinaka <todd.fujinaka@intel.com>


^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-14 21:51                       ` Heiner Kallweit
  0 siblings, 0 replies; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-14 21:51 UTC (permalink / raw)
  To: intel-wired-lan

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.

> Todd Fujinaka <todd.fujinaka@intel.com>


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-14 17:07         ` Heiner Kallweit
@ 2021-09-14 21:55           ` Bjorn Helgaas
  2021-09-14 22:06             ` Heiner Kallweit
  0 siblings, 1 reply; 53+ messages in thread
From: Bjorn Helgaas @ 2021-09-14 21:55 UTC (permalink / raw)
  To: Heiner Kallweit; +Cc: Dave Jones, Linus Torvalds, linux-kernel, linux-pci

On Tue, Sep 14, 2021 at 07:07:40PM +0200, Heiner Kallweit wrote:
> On 14.09.2021 13:26, Bjorn Helgaas wrote:
> > On Tue, Sep 14, 2021 at 08:21:46AM +0200, Heiner Kallweit wrote:
> >> On 14.09.2021 01:46, Bjorn Helgaas wrote:
> > 
> >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
> >>>  /*
> >>
> >> Leaving the quirks in FIXUP_HEADER stage would have the advantage that for
> >> blacklisted devices the vpd sysfs attribute isn't visibale. The needed
> >> changes to the patch are minimal.
> > 
> > What do you have in mind?  The only thing I can think of would be to
> > add a "pci_dev.no_vpd" bit.  "vpd.cap == 0" means the device has no
> > VPD, and "vpd.len == 0" means we haven't determined the size yet.  All
> > devices start off with vpd.cap == 0 and vpd.len == 0, so a
> > FIXUP_HEADER quirk would have to set a sentinel value or some other
> > bit.
> 
> Why not leave vpd.len == PCI_VPD_SZ_INVALID as sentinel?

Sentinel values aren't really my favorite thing, but it certainly does
have the advantage of hiding the sysfs attribute.

> And one more question: Why do you move the "if (!vpd->cap)" check from
> pci_vpd_read() to pci_read_vpd()? At a first glance I see no benefit.

I'm pretty sure I *had* a reason, but I can't remember right now :(
Moving it sure does uglify pci_read_vpd() and pci_write_vpd(), though.

What do you think of the following?  (This is a diff from v5.15-rc1.)

diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
index 25557b272a4f..4be24890132e 100644
--- a/drivers/pci/vpd.c
+++ b/drivers/pci/vpd.c
@@ -99,6 +99,24 @@ static size_t pci_vpd_size(struct pci_dev *dev)
 	return off ?: PCI_VPD_SZ_INVALID;
 }
 
+static bool pci_vpd_available(struct pci_dev *dev)
+{
+	struct pci_vpd *vpd = &dev->vpd;
+
+	if (!vpd->cap)
+		return false;
+
+	if (vpd->len == 0) {
+		vpd->len = pci_vpd_size(dev);
+		if (vpd->len == PCI_VPD_SZ_INVALID) {
+			vpd->cap = 0;
+			return false;
+		}
+	}
+
+	return true;
+}
+
 /*
  * Wait for last operation to complete.
  * This code has to spin since there is no other notification from the PCI
@@ -145,7 +163,7 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
 	loff_t end = pos + count;
 	u8 *buf = arg;
 
-	if (!vpd->cap)
+	if (!pci_vpd_available(dev))
 		return -ENODEV;
 
 	if (pos < 0)
@@ -206,7 +224,7 @@ static ssize_t pci_vpd_write(struct pci_dev *dev, loff_t pos, size_t count,
 	loff_t end = pos + count;
 	int ret = 0;
 
-	if (!vpd->cap)
+	if (!pci_vpd_available(dev))
 		return -ENODEV;
 
 	if (pos < 0 || (pos & 3) || (count & 3))
@@ -242,14 +260,11 @@ static ssize_t pci_vpd_write(struct pci_dev *dev, loff_t pos, size_t count,
 
 void pci_vpd_init(struct pci_dev *dev)
 {
+	if (dev->vpd.len == PCI_VPD_SZ_INVALID)
+		return;
+
 	dev->vpd.cap = pci_find_capability(dev, PCI_CAP_ID_VPD);
 	mutex_init(&dev->vpd.lock);
-
-	if (!dev->vpd.len)
-		dev->vpd.len = pci_vpd_size(dev);
-
-	if (dev->vpd.len == PCI_VPD_SZ_INVALID)
-		dev->vpd.cap = 0;
 }
 
 static ssize_t vpd_read(struct file *filp, struct kobject *kobj,
@@ -294,13 +309,14 @@ const struct attribute_group pci_dev_vpd_attr_group = {
 
 void *pci_vpd_alloc(struct pci_dev *dev, unsigned int *size)
 {
-	unsigned int len = dev->vpd.len;
+	unsigned int len;
 	void *buf;
 	int cnt;
 
-	if (!dev->vpd.cap)
+	if (!pci_vpd_available(dev))
 		return ERR_PTR(-ENODEV);
 
+	len = dev->vpd.len;
 	buf = kmalloc(len, GFP_KERNEL);
 	if (!buf)
 		return ERR_PTR(-ENOMEM);

^ permalink raw reply related	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-14 21:55           ` Bjorn Helgaas
@ 2021-09-14 22:06             ` Heiner Kallweit
  2021-09-14 22:33               ` Dave Jones
  0 siblings, 1 reply; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-14 22:06 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: Dave Jones, Linus Torvalds, linux-kernel, linux-pci

On 14.09.2021 23:55, Bjorn Helgaas wrote:
> On Tue, Sep 14, 2021 at 07:07:40PM +0200, Heiner Kallweit wrote:
>> On 14.09.2021 13:26, Bjorn Helgaas wrote:
>>> On Tue, Sep 14, 2021 at 08:21:46AM +0200, Heiner Kallweit wrote:
>>>> On 14.09.2021 01:46, Bjorn Helgaas wrote:
>>>
>>>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
>>>>>  /*
>>>>
>>>> Leaving the quirks in FIXUP_HEADER stage would have the advantage that for
>>>> blacklisted devices the vpd sysfs attribute isn't visibale. The needed
>>>> changes to the patch are minimal.
>>>
>>> What do you have in mind?  The only thing I can think of would be to
>>> add a "pci_dev.no_vpd" bit.  "vpd.cap == 0" means the device has no
>>> VPD, and "vpd.len == 0" means we haven't determined the size yet.  All
>>> devices start off with vpd.cap == 0 and vpd.len == 0, so a
>>> FIXUP_HEADER quirk would have to set a sentinel value or some other
>>> bit.
>>
>> Why not leave vpd.len == PCI_VPD_SZ_INVALID as sentinel?
> 
> Sentinel values aren't really my favorite thing, but it certainly does
> have the advantage of hiding the sysfs attribute.
> 
>> And one more question: Why do you move the "if (!vpd->cap)" check from
>> pci_vpd_read() to pci_read_vpd()? At a first glance I see no benefit.
> 
> I'm pretty sure I *had* a reason, but I can't remember right now :(
> Moving it sure does uglify pci_read_vpd() and pci_write_vpd(), though.
> 
> What do you think of the following?  (This is a diff from v5.15-rc1.)
> 
> diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
> index 25557b272a4f..4be24890132e 100644
> --- a/drivers/pci/vpd.c
> +++ b/drivers/pci/vpd.c
> @@ -99,6 +99,24 @@ static size_t pci_vpd_size(struct pci_dev *dev)
>  	return off ?: PCI_VPD_SZ_INVALID;
>  }
>  
> +static bool pci_vpd_available(struct pci_dev *dev)
> +{
> +	struct pci_vpd *vpd = &dev->vpd;
> +
> +	if (!vpd->cap)
> +		return false;
> +
> +	if (vpd->len == 0) {
> +		vpd->len = pci_vpd_size(dev);
> +		if (vpd->len == PCI_VPD_SZ_INVALID) {
> +			vpd->cap = 0;
> +			return false;
> +		}
> +	}
> +
> +	return true;
> +}
> +
>  /*
>   * Wait for last operation to complete.
>   * This code has to spin since there is no other notification from the PCI
> @@ -145,7 +163,7 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
>  	loff_t end = pos + count;
>  	u8 *buf = arg;
>  
> -	if (!vpd->cap)
> +	if (!pci_vpd_available(dev))
>  		return -ENODEV;
>  
>  	if (pos < 0)
> @@ -206,7 +224,7 @@ static ssize_t pci_vpd_write(struct pci_dev *dev, loff_t pos, size_t count,
>  	loff_t end = pos + count;
>  	int ret = 0;
>  
> -	if (!vpd->cap)
> +	if (!pci_vpd_available(dev))
>  		return -ENODEV;
>  
>  	if (pos < 0 || (pos & 3) || (count & 3))
> @@ -242,14 +260,11 @@ static ssize_t pci_vpd_write(struct pci_dev *dev, loff_t pos, size_t count,
>  
>  void pci_vpd_init(struct pci_dev *dev)
>  {
> +	if (dev->vpd.len == PCI_VPD_SZ_INVALID)
> +		return;
> +
>  	dev->vpd.cap = pci_find_capability(dev, PCI_CAP_ID_VPD);
>  	mutex_init(&dev->vpd.lock);
> -
> -	if (!dev->vpd.len)
> -		dev->vpd.len = pci_vpd_size(dev);
> -
> -	if (dev->vpd.len == PCI_VPD_SZ_INVALID)
> -		dev->vpd.cap = 0;
>  }
>  
>  static ssize_t vpd_read(struct file *filp, struct kobject *kobj,
> @@ -294,13 +309,14 @@ const struct attribute_group pci_dev_vpd_attr_group = {
>  
>  void *pci_vpd_alloc(struct pci_dev *dev, unsigned int *size)
>  {
> -	unsigned int len = dev->vpd.len;
> +	unsigned int len;
>  	void *buf;
>  	int cnt;
>  
> -	if (!dev->vpd.cap)
> +	if (!pci_vpd_available(dev))
>  		return ERR_PTR(-ENODEV);
>  
> +	len = dev->vpd.len;
>  	buf = kmalloc(len, GFP_KERNEL);
>  	if (!buf)
>  		return ERR_PTR(-ENOMEM);
> 

This looks very good to me.

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-14 22:06             ` Heiner Kallweit
@ 2021-09-14 22:33               ` Dave Jones
  2021-09-15 21:31                 ` Bjorn Helgaas
  0 siblings, 1 reply; 53+ messages in thread
From: Dave Jones @ 2021-09-14 22:33 UTC (permalink / raw)
  To: Heiner Kallweit; +Cc: Bjorn Helgaas, Linus Torvalds, linux-kernel, linux-pci

On Wed, Sep 15, 2021 at 12:06:33AM +0200, Heiner Kallweit wrote:

 > > What do you think of the following?  (This is a diff from v5.15-rc1.)
 > > 
 > 
 > This looks very good to me.

fwiw, I tested this too, and it still works.

	Dave

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-14 21:51                       ` Heiner Kallweit
@ 2021-09-15 14:18                         ` Hisashi T Fujinaka
  -1 siblings, 0 replies; 53+ messages in thread
From: Hisashi T Fujinaka @ 2021-09-15 14:18 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Dave Jones, linux-pci, Linux Kernel Mailing List,
	intel-wired-lan, Bjorn Helgaas

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@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@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.

Todd Fujinaka <todd.fujinaka@intel.com>

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-15 14:18                         ` Hisashi T Fujinaka
  0 siblings, 0 replies; 53+ messages in thread
From: Hisashi T Fujinaka @ 2021-09-15 14:18 UTC (permalink / raw)
  To: intel-wired-lan

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.

Todd Fujinaka <todd.fujinaka@intel.com>

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-15 14:18                         ` Hisashi T Fujinaka
@ 2021-09-15 16:05                           ` Heiner Kallweit
  -1 siblings, 0 replies; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-15 16:05 UTC (permalink / raw)
  To: Hisashi T Fujinaka
  Cc: Dave Jones, linux-pci, Linux Kernel Mailing List,
	intel-wired-lan, Bjorn Helgaas

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@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@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 <todd.fujinaka@intel.com>


^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-15 16:05                           ` Heiner Kallweit
  0 siblings, 0 replies; 53+ messages in thread
From: Heiner Kallweit @ 2021-09-15 16:05 UTC (permalink / raw)
  To: intel-wired-lan

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 <todd.fujinaka@intel.com>


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-15 16:05                           ` Heiner Kallweit
@ 2021-09-15 16:16                             ` Hisashi T Fujinaka
  -1 siblings, 0 replies; 53+ messages in thread
From: Hisashi T Fujinaka @ 2021-09-15 16:16 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Dave Jones, linux-pci, Linux Kernel Mailing List,
	intel-wired-lan, Bjorn Helgaas

On Wed, 15 Sep 2021, Heiner Kallweit wrote:

> 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@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@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.

Huh. I didn't realize there was an official list beyond pciids.ucw.cz.

In any case, that's who you need to talk to about the unlisted (to
Linux) vendor ID and also the odd VPD data.

-- 
Hisashi T Fujinaka - htodd@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-15 16:16                             ` Hisashi T Fujinaka
  0 siblings, 0 replies; 53+ messages in thread
From: Hisashi T Fujinaka @ 2021-09-15 16:16 UTC (permalink / raw)
  To: intel-wired-lan

On Wed, 15 Sep 2021, Heiner Kallweit wrote:

> 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.

Huh. I didn't realize there was an official list beyond pciids.ucw.cz.

In any case, that's who you need to talk to about the unlisted (to
Linux) vendor ID and also the odd VPD data.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-14 22:33               ` Dave Jones
@ 2021-09-15 21:31                 ` Bjorn Helgaas
  0 siblings, 0 replies; 53+ messages in thread
From: Bjorn Helgaas @ 2021-09-15 21:31 UTC (permalink / raw)
  To: Dave Jones, Heiner Kallweit, Linus Torvalds, linux-kernel, linux-pci

On Tue, Sep 14, 2021 at 06:33:27PM -0400, Dave Jones wrote:
> On Wed, Sep 15, 2021 at 12:06:33AM +0200, Heiner Kallweit wrote:
> 
>  > > What do you think of the following?  (This is a diff from v5.15-rc1.)
>  > > 
>  > 
>  > This looks very good to me.
> 
> fwiw, I tested this too, and it still works.

Thanks very much for proactively testing this.  I hated to burden you
before anybody else had looked at it.

I added this to for-linus for v5.15.

Bjorn

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-15 16:16                             ` Hisashi T Fujinaka
@ 2021-09-15 22:32                               ` Bjorn Helgaas
  -1 siblings, 0 replies; 53+ messages in thread
From: Bjorn Helgaas @ 2021-09-15 22:32 UTC (permalink / raw)
  To: Hisashi T Fujinaka
  Cc: Heiner Kallweit, Dave Jones, linux-pci,
	Linux Kernel Mailing List, intel-wired-lan, Bjorn Helgaas

On Wed, Sep 15, 2021 at 09:16:47AM -0700, Hisashi T Fujinaka wrote:
> On Wed, 15 Sep 2021, Heiner Kallweit wrote:
> > 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:

> > > > > 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.

A series of 0x03 0x03 0x03 ... bytes would decode as "small items of
type 00", so I assume the VPD contains a series of 0x33 0x33 0x33 ...
bytes.  That would decode to a series of "small items of type 06",
each of length four (one byte for the tag, three bytes of data).

Prior to v5.15, we would complain "invalid short VPD tag 06" and stop
reading.  As of v5.15, I think we'll just keep reading looking for a
valid "end" tag, but we'll never find one.

I think in v5.15 there will be no error message because the series of
four-byte small data items happens to fit exactly in the maximum 32KB
size of VPD and is technically legal syntactic structure, even though
it makes no sense.

But it will be much slower and might account for the boot slowdown
Dave reported.

> > 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.
> 
> Huh. I didn't realize there was an official list beyond pciids.ucw.cz.
> 
> In any case, that's who you need to talk to about the unlisted (to
> Linux) vendor ID and also the odd VPD data.

https://pci-ids.ucw.cz/ is definitely unofficial in the sense that it
is basically crowd-sourced data, not the "official" Vendor IDs
controlled by the PCI SIG.

I submitted an addition to https://pci-ids.ucw.cz/

Bjorn

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-15 22:32                               ` Bjorn Helgaas
  0 siblings, 0 replies; 53+ messages in thread
From: Bjorn Helgaas @ 2021-09-15 22:32 UTC (permalink / raw)
  To: intel-wired-lan

On Wed, Sep 15, 2021 at 09:16:47AM -0700, Hisashi T Fujinaka wrote:
> On Wed, 15 Sep 2021, Heiner Kallweit wrote:
> > 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:

> > > > > 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.

A series of 0x03 0x03 0x03 ... bytes would decode as "small items of
type 00", so I assume the VPD contains a series of 0x33 0x33 0x33 ...
bytes.  That would decode to a series of "small items of type 06",
each of length four (one byte for the tag, three bytes of data).

Prior to v5.15, we would complain "invalid short VPD tag 06" and stop
reading.  As of v5.15, I think we'll just keep reading looking for a
valid "end" tag, but we'll never find one.

I think in v5.15 there will be no error message because the series of
four-byte small data items happens to fit exactly in the maximum 32KB
size of VPD and is technically legal syntactic structure, even though
it makes no sense.

But it will be much slower and might account for the boot slowdown
Dave reported.

> > 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.
> 
> Huh. I didn't realize there was an official list beyond pciids.ucw.cz.
> 
> In any case, that's who you need to talk to about the unlisted (to
> Linux) vendor ID and also the odd VPD data.

https://pci-ids.ucw.cz/ is definitely unofficial in the sense that it
is basically crowd-sourced data, not the "official" Vendor IDs
controlled by the PCI SIG.

I submitted an addition to https://pci-ids.ucw.cz/

Bjorn

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-15 22:32                               ` Bjorn Helgaas
@ 2021-09-15 23:46                                 ` Hisashi T Fujinaka
  -1 siblings, 0 replies; 53+ messages in thread
From: Hisashi T Fujinaka @ 2021-09-15 23:46 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Dave Jones, linux-pci, Linux Kernel Mailing List,
	intel-wired-lan, Bjorn Helgaas, Heiner Kallweit

On Wed, 15 Sep 2021, Bjorn Helgaas wrote:

> On Wed, Sep 15, 2021 at 09:16:47AM -0700, Hisashi T Fujinaka wrote:
>> On Wed, 15 Sep 2021, Heiner Kallweit wrote:
>>> 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:
>
>>>>>> 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.
>
> A series of 0x03 0x03 0x03 ... bytes would decode as "small items of
> type 00", so I assume the VPD contains a series of 0x33 0x33 0x33 ...
> bytes.  That would decode to a series of "small items of type 06",
> each of length four (one byte for the tag, three bytes of data).
>
> Prior to v5.15, we would complain "invalid short VPD tag 06" and stop
> reading.  As of v5.15, I think we'll just keep reading looking for a
> valid "end" tag, but we'll never find one.
>
> I think in v5.15 there will be no error message because the series of
> four-byte small data items happens to fit exactly in the maximum 32KB
> size of VPD and is technically legal syntactic structure, even though
> it makes no sense.
>
> But it will be much slower and might account for the boot slowdown
> Dave reported.
>
>>> 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.
>>
>> Huh. I didn't realize there was an official list beyond pciids.ucw.cz.
>>
>> In any case, that's who you need to talk to about the unlisted (to
>> Linux) vendor ID and also the odd VPD data.
>
> https://pci-ids.ucw.cz/ is definitely unofficial in the sense that it
> is basically crowd-sourced data, not the "official" Vendor IDs
> controlled by the PCI SIG.
>
> I submitted an addition to https://pci-ids.ucw.cz/
>
> Bjorn

Just for my edumacation, do they keep track of device IDs, subvendor IDs
(which are probably just the same as vendor IDs), and subdevice IDs in
the PCI SIG? Or even the branding strings?

Todd Fujinaka <todd.fujinaka@intel.com>

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-15 23:46                                 ` Hisashi T Fujinaka
  0 siblings, 0 replies; 53+ messages in thread
From: Hisashi T Fujinaka @ 2021-09-15 23:46 UTC (permalink / raw)
  To: intel-wired-lan

On Wed, 15 Sep 2021, Bjorn Helgaas wrote:

> On Wed, Sep 15, 2021 at 09:16:47AM -0700, Hisashi T Fujinaka wrote:
>> On Wed, 15 Sep 2021, Heiner Kallweit wrote:
>>> 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:
>
>>>>>> 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.
>
> A series of 0x03 0x03 0x03 ... bytes would decode as "small items of
> type 00", so I assume the VPD contains a series of 0x33 0x33 0x33 ...
> bytes.  That would decode to a series of "small items of type 06",
> each of length four (one byte for the tag, three bytes of data).
>
> Prior to v5.15, we would complain "invalid short VPD tag 06" and stop
> reading.  As of v5.15, I think we'll just keep reading looking for a
> valid "end" tag, but we'll never find one.
>
> I think in v5.15 there will be no error message because the series of
> four-byte small data items happens to fit exactly in the maximum 32KB
> size of VPD and is technically legal syntactic structure, even though
> it makes no sense.
>
> But it will be much slower and might account for the boot slowdown
> Dave reported.
>
>>> 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.
>>
>> Huh. I didn't realize there was an official list beyond pciids.ucw.cz.
>>
>> In any case, that's who you need to talk to about the unlisted (to
>> Linux) vendor ID and also the odd VPD data.
>
> https://pci-ids.ucw.cz/ is definitely unofficial in the sense that it
> is basically crowd-sourced data, not the "official" Vendor IDs
> controlled by the PCI SIG.
>
> I submitted an addition to https://pci-ids.ucw.cz/
>
> Bjorn

Just for my edumacation, do they keep track of device IDs, subvendor IDs
(which are probably just the same as vendor IDs), and subdevice IDs in
the PCI SIG? Or even the branding strings?

Todd Fujinaka <todd.fujinaka@intel.com>

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
  2021-09-15 23:46                                 ` Hisashi T Fujinaka
@ 2021-09-17 15:09                                   ` Bjorn Helgaas
  -1 siblings, 0 replies; 53+ messages in thread
From: Bjorn Helgaas @ 2021-09-17 15:09 UTC (permalink / raw)
  To: Hisashi T Fujinaka
  Cc: Dave Jones, linux-pci, Linux Kernel Mailing List,
	intel-wired-lan, Bjorn Helgaas, Heiner Kallweit

On Wed, Sep 15, 2021 at 04:46:54PM -0700, Hisashi T Fujinaka wrote:
> On Wed, 15 Sep 2021, Bjorn Helgaas wrote:
> 
> > On Wed, Sep 15, 2021 at 09:16:47AM -0700, Hisashi T Fujinaka wrote:
> > > On Wed, 15 Sep 2021, Heiner Kallweit wrote:

> > > > 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.
> > > 
> > > Huh. I didn't realize there was an official list beyond pciids.ucw.cz.
> > > 
> > > In any case, that's who you need to talk to about the unlisted (to
> > > Linux) vendor ID and also the odd VPD data.
> > 
> > https://pci-ids.ucw.cz/ is definitely unofficial in the sense that it
> > is basically crowd-sourced data, not the "official" Vendor IDs
> > controlled by the PCI SIG.
> > 
> > I submitted an addition to https://pci-ids.ucw.cz/
> > 
> > Bjorn
> 
> Just for my edumacation, do they keep track of device IDs, subvendor IDs
> (which are probably just the same as vendor IDs), and subdevice IDs in
> the PCI SIG? Or even the branding strings?

The PCI SIG does not manage Device IDs.  That's the responsibility of
the vendor.

^ permalink raw reply	[flat|nested] 53+ messages in thread

* [Intel-wired-lan] Linux 5.15-rc1 - 82599ES VPD access isue
@ 2021-09-17 15:09                                   ` Bjorn Helgaas
  0 siblings, 0 replies; 53+ messages in thread
From: Bjorn Helgaas @ 2021-09-17 15:09 UTC (permalink / raw)
  To: intel-wired-lan

On Wed, Sep 15, 2021 at 04:46:54PM -0700, Hisashi T Fujinaka wrote:
> On Wed, 15 Sep 2021, Bjorn Helgaas wrote:
> 
> > On Wed, Sep 15, 2021 at 09:16:47AM -0700, Hisashi T Fujinaka wrote:
> > > On Wed, 15 Sep 2021, Heiner Kallweit wrote:

> > > > 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.
> > > 
> > > Huh. I didn't realize there was an official list beyond pciids.ucw.cz.
> > > 
> > > In any case, that's who you need to talk to about the unlisted (to
> > > Linux) vendor ID and also the odd VPD data.
> > 
> > https://pci-ids.ucw.cz/ is definitely unofficial in the sense that it
> > is basically crowd-sourced data, not the "official" Vendor IDs
> > controlled by the PCI SIG.
> > 
> > I submitted an addition to https://pci-ids.ucw.cz/
> > 
> > Bjorn
> 
> Just for my edumacation, do they keep track of device IDs, subvendor IDs
> (which are probably just the same as vendor IDs), and subdevice IDs in
> the PCI SIG? Or even the branding strings?

The PCI SIG does not manage Device IDs.  That's the responsibility of
the vendor.

^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-13  3:57 ` Guenter Roeck
@ 2021-09-28 23:18   ` Michael S. Tsirkin
  2021-09-30 13:44     ` Guenter Roeck
  0 siblings, 1 reply; 53+ messages in thread
From: Michael S. Tsirkin @ 2021-09-28 23:18 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: Linux Kernel Mailing List

On Sun, Sep 12, 2021 at 08:57:50PM -0700, Guenter Roeck wrote:
> The qemu runtime failure bisects to commit 694a1116b405 ("virtio: Bind
> virtio device to device-tree node"), and reverting that commit fixes the
> problem.  With that patch applied, the virtio block device does not
> instantiate on sparc64. This results in a crash since that is where the
> test is trying to boot from.
> 
> Good news is that I don't see any new runtime warnings.
> 
> Guenter

I think the fix is now merged by Linus - could you please try it out and
confirm that it's ok?

Thanks a lot for the testing!

-- 
MST


^ permalink raw reply	[flat|nested] 53+ messages in thread

* Re: Linux 5.15-rc1
  2021-09-28 23:18   ` Michael S. Tsirkin
@ 2021-09-30 13:44     ` Guenter Roeck
  0 siblings, 0 replies; 53+ messages in thread
From: Guenter Roeck @ 2021-09-30 13:44 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: Linux Kernel Mailing List

On Tue, Sep 28, 2021 at 07:18:41PM -0400, Michael S. Tsirkin wrote:
> On Sun, Sep 12, 2021 at 08:57:50PM -0700, Guenter Roeck wrote:
> > The qemu runtime failure bisects to commit 694a1116b405 ("virtio: Bind
> > virtio device to device-tree node"), and reverting that commit fixes the
> > problem.  With that patch applied, the virtio block device does not
> > instantiate on sparc64. This results in a crash since that is where the
> > test is trying to boot from.
> > 
> > Good news is that I don't see any new runtime warnings.
> > 
> > Guenter
> 
> I think the fix is now merged by Linus - could you please try it out and
> confirm that it's ok?

Yes, it is.

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 53+ messages in thread

end of thread, other threads:[~2021-09-30 13:44 UTC | newest]

Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-12 23:58 Linux 5.15-rc1 Linus Torvalds
2021-09-13  3:57 ` Guenter Roeck
2021-09-28 23:18   ` Michael S. Tsirkin
2021-09-30 13:44     ` Guenter Roeck
2021-09-13 14:18 ` Dave Jones
2021-09-13 18:59   ` Heiner Kallweit
2021-09-13 19:51     ` Linus Torvalds
2021-09-13 20:09       ` Bjorn Helgaas
2021-09-13 20:11       ` Heiner Kallweit
2021-09-13 20:15         ` Linus Torvalds
2021-09-13 20:15     ` Dave Jones
2021-09-13 20:22       ` Heiner Kallweit
2021-09-13 20:32         ` Dave Jones
2021-09-13 20:44           ` Linux 5.15-rc1 - 82599ES VPD access isue Heiner Kallweit
2021-09-13 20:44             ` [Intel-wired-lan] " Heiner Kallweit
2021-09-13 23:32             ` Hisashi T Fujinaka
2021-09-13 23:32               ` Hisashi T Fujinaka
2021-09-14  5:51               ` Heiner Kallweit
2021-09-14  5:51                 ` Heiner Kallweit
2021-09-14 14:24                 ` Dave Jones
2021-09-14 14:24                   ` Dave Jones
2021-09-14 18:28                   ` Fujinaka, Todd
2021-09-14 18:28                     ` Fujinaka, Todd
2021-09-14 20:00                   ` Hisashi T Fujinaka
2021-09-14 20:00                     ` Hisashi T Fujinaka
2021-09-14 21:51                     ` Heiner Kallweit
2021-09-14 21:51                       ` Heiner Kallweit
2021-09-15 14:18                       ` Hisashi T Fujinaka
2021-09-15 14:18                         ` Hisashi T Fujinaka
2021-09-15 16:05                         ` Heiner Kallweit
2021-09-15 16:05                           ` Heiner Kallweit
2021-09-15 16:16                           ` Hisashi T Fujinaka
2021-09-15 16:16                             ` Hisashi T Fujinaka
2021-09-15 22:32                             ` Bjorn Helgaas
2021-09-15 22:32                               ` Bjorn Helgaas
2021-09-15 23:46                               ` Hisashi T Fujinaka
2021-09-15 23:46                                 ` Hisashi T Fujinaka
2021-09-17 15:09                                 ` Bjorn Helgaas
2021-09-17 15:09                                   ` Bjorn Helgaas
2021-09-13 20:59           ` Linux 5.15-rc1 Heiner Kallweit
2021-09-13 23:35             ` Bjorn Helgaas
2021-09-13 20:32       ` Heiner Kallweit
2021-09-13 20:36         ` Linus Torvalds
2021-09-13 20:41         ` Dave Jones
2021-09-13 23:46   ` Bjorn Helgaas
2021-09-14  0:39     ` Dave Jones
2021-09-14  6:21     ` Heiner Kallweit
2021-09-14 11:26       ` Bjorn Helgaas
2021-09-14 17:07         ` Heiner Kallweit
2021-09-14 21:55           ` Bjorn Helgaas
2021-09-14 22:06             ` Heiner Kallweit
2021-09-14 22:33               ` Dave Jones
2021-09-15 21:31                 ` Bjorn Helgaas

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.