update pci.ids to the latest version - 2026.07.31

[pamanseau]

Syncs pkg/pciids/default_pci.ids from Version 2025.07.11 (the last sync, PR #66) to the latest upstream pci.ids release (Version 2026.07.31, https://pci-ids.ucw.cz/v2.2/pci.ids). Generated with make update-pcidb.

Follows the exact pattern of the prior manual syncs (#66, #55, #52, #46, #42). The last sync landed a year ago today (2025-07-31); this catches up the ~3.3k additions / ~0.9k deletions that accumulated since.

Why this matters: B300 (0x3182) missing → UNKNOWN_DEVICE resource name

The previous sync (2025.07.11) predates the NVIDIA B300 (Blackwell Ultra). The upstream pci.ids now contains the entry; this PR pulls it in:

3180  GB110 [Reserved Dev ID A]
3182  GB110 [B300 SXM6 AC]      <- added
31a1  GB110 [GB300 MaxQ]
31c0  GB110 [Reserved Dev ID B]
31c2  GB110 [GB300]
31c3  GB110 [GB300]
31fe  GB110

Without 0x3182 in this database, pkg/nvpci falls back to UnknownDeviceString = "UNKNOWN_DEVICE" (nvpci.go:44) when a B300 is enumerated. Downstream, the nvidia-sandbox-device-plugin (which vendors go-nvlib and uses it to name the Kata passthrough GPU resource) then advertises nvidia.com/UNKNOWN_DEVICE=8 on B300 nodes instead of a model-specific name. The GPUs are fully functional for VFIO passthrough — only the resource name is wrong, so CC pods requesting nvidia.com/pgpu: 8 (or a model-specific name) fail to schedule with Insufficient nvidia.com/pgpu.

Verified on a production B300 node (2026-07-31)

$ lspci -nn -d 10de:3182 | head -2
12:00.0 3D controller [0302]: NVIDIA Corporation GB110 [B300 SXM6 AC] [10de:3182] (rev a1)
3a:00.0 3D controller [0302]: NVIDIA Corporation GB110 [B300 SXM6 AC] [10de:3182] (rev a1)
... (8x total)

$ kubectl get node am-b300-62 -o jsonpath='{.status.allocatable}' | jq 'with_entries(select(.key | test("nvidia")))'
{ "nvidia.com/UNKNOWN_DEVICE": "8" }   # <- should be a model-specific name

# sandbox-device-plugin logs:
# Found GPU UNKNOWN_DEVICE [3182] at 0000:12:00.0 (iommufd: vfio0)
# Registering device plugin "UNKNOWN_DEVICE" with 8 device(s)

For comparison, a B200 node (PCI 0x2901, present in the 2025.07.11 pci.ids) advertises nvidia.com/GB100_B200=8 — the lookup succeeds and the resource gets a proper name.

Related issues

• [Bug]: nvidia-operator-validator fails to find device ID '3182' (B300) on K8s 1.33 / Ubuntu 24.04 gpu-operator#2231 — nvidia-operator-validator fails to find device ID '3182' (B300) (the validator's own lookup gap; a different code path but the same root cause)
• Update default vGPU devices config for vGPU 20.0 gpu-operator#2625 — added 0x318210DE to the vGPU device-manager configmap (merged). Fixes the vGPU path but NOT the Kata sandbox-device-plugin path (which reads this pci.ids).
• Issue processing pci.ids in vm-passthrough causes resourcename to fail and second device not to be registered gpu-operator#551 — the identical bug class in 2023 (nvidia.com/2571 instead of a model name due to a stale pci.ids). Resolved by shipping a newer pci.ids — same fix pattern as this PR.
• Unable to run GPU workload on B200/B300 with mutliple pgpu assigned (more than 3) kata-containers/kata-containers#13270 — Unable to run GPU workload on B200/B300 with multiple pgpu assigned (more than 3) (open). A separate Kata/QEMU VFIO limitation on B200/B300, not the resource-naming bug — but linked for discoverability since both surface on B200/B300 CC nodes.

Scope

Single file change: pkg/pciids/default_pci.ids (+3355 / −892). No Go code touched. The new file is the verbatim output of make update-pcidb (wget of the upstream pci.ids).

Checklist

• Generated with make update-pcidb (no manual edits)
• No Go code changes
• 0x3182 GB110 [B300 SXM6 AC] confirmed present in the new file
• Existing entries intact (H100 0x2335, H200 0x2335, B200 0x2901, HGX GB200 0x2941 all still present)
• File well-formed (42856 lines, terminates cleanly with the C ff Unassigned class class entry)

Made with Cursor

[myeolenv]

Thanks for the contribution. We will review this PR.

[tariq1890]

@pamanseau , Please ensure that your commit meets the two requirements below:

• Passes the DCO check (--signoff your commit)
• Your commit is signed.