I can confirm this bug on independent hardware, and I have some additionalanalysis suggesting it is systematic rather than configuration-specific.
Reproduction
------------
Same failure, different machine:
nvidia-open-kernel-dkms 550.163.01-2
dkms 3.2.2-1~deb13u1
gcc Debian 14.2.0-19 (14.2.0)
Debian GNU/Linux 13 (trixie)
GPU: NVIDIA GA106M [GeForce RTX 3060 Mobile / Max-Q] [10de:2520]
(hybrid/Optimus alongside Intel Alder Lake-P Iris Xe)
Build against 6.12.100+deb13-amd64 fails at the same location:
nvidia/nv-pci.c:237:9: error: too few arguments to function
'pci_resize_resource'
Building the same source against 6.12.96+deb13-amd64 succeeds.
Root cause
----------
The prototype gained a fourth parameter between the two kernels.
6.12.96, /usr/src/linux-headers-6.12.96+deb13-common/include/linux/pci.h:1421
int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size);
6.12.100, /usr/src/linux-headers-6.12.100+deb13-common/include/linux/pci.h:1421
int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size,
int exclude_bars);
Why this is not configuration-dependent
---------------------------------------
This is the part I think is worth adding to the report: the driver has no
compatibility shim for this symbol at all.
1. pci_resize_resource appears exactly once in the unpacked source tree:
$ grep -rn pci_resize_resource . --include='*.c' --include='*.h'
./nvidia/nv-pci.c:237: r = pci_resize_resource(pci_dev, NV_GPU_BAR1, requested_size);
2. conftest.sh does not probe it:
$ grep -c pci_resize_resource conftest.sh
0
...while it does probe many other PCI symbols (pci_bus_address,
pci_channel_state, pci_enable_msix_range, pci_get_domain_bus_and_slot,
pci_driver_has_driver_managed_dma, and others), which is the mechanism
the driver normally uses to absorb this kind of API change.
3. The call site is not inside any preprocessor conditional. The nearest
#endif above it closes an unrelated
NV_IS_EXPORT_SYMBOL_PRESENT_pci_find_host_bridge block.
So the call is unconditional and there is no code path that can adapt to the
new signature. Any build of 550.163.01 against a kernel carrying the
4-argument prototype will fail identically, regardless of GPU model, Optimus
versus discrete-only, or local configuration.
Scope across suites
-------------------
No currently packaged revision fixes this:
bookworm 535.261.03-1
trixie 550.163.01-2
trixie-backports 550.163.01-4~bpo13+1
sid 550.163.01-4
experimental 555.58.02-2
trixie-backports is worth calling out explicitly, since it is the natural
first thing an affected user will reach for. It is the same upstream
550.163.01, and the Debian revisions since -2 do not touch this code path:
per the changelog, -3 backported the NV_DMA_BUF_HAS_DYNAMIC_ATTACHMENT
changes to fix the open kernel module build for Linux 6.16, and -4 was a
sync with src:nvidia-graphics-drivers. Installing the backport rebuilds the
same source and fails the same way.
Impact
------
The DKMS failure makes the linux-image postinst exit non-zero, which leaves
the kernel packages unconfigured and blocks dpkg:
iF linux-image-6.12.100+deb13-amd64
iU linux-image-amd64
iU linux-headers-6.12.100+deb13-amd64
iU linux-headers-amd64
Users who reboot into 6.12.100 before noticing will come up with no NVIDIA
driver. On this machine the other DKMS modules (acpi-call, kbdlight, xtrx)
all built successfully against 6.12.100; nvidia-current-open was the only
failure.
I have not checked whether nvidia-kernel-dkms (non-free) shares this call
site and is affected in the same way. It is not installed here, so I cannot
confirm either way.
Workaround
----------
Staying on 6.12.96+deb13-amd64, with linux-image-amd64 and
linux-headers-amd64 held, until a fixed driver is available.