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.
signature.asc
Description: OpenPGP digital signature
