[Bug 289647] graphics/drm-61-kmod: X11 with nvidia-drm-61-kmod fails to start after commit ac934345a14f

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 17 Sep 2025 17:45:30 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289647

--- Comment #10 from Jean-Sébastien Pédron <dumbbell@FreeBSD.org> ---
Therefore, it is value of the PCI slot which changes between both sysctls.

The old value was computed like this:

    slot = pci_get_slot(bsddev);

The new value is computed like this:

    slot = PCI_SLOT(pdev->devfn);

`pdev->devfn` is computed like this by linux_pci_attach_device() in linuxkpi
(linux_pci.c):

    if (isdrm)
        PCI_GET_ID(device_get_parent(parent), parent, PCI_ID_RID, &rid);
    else
        PCI_GET_ID(parent, dev, PCI_ID_RID, &rid);
    pdev->devfn = rid;

The `isdrm` boolean is true if the driver name is "drmn", which is probably (?)
not the case for the NVIDIA drivers. So I assume `devfn` is computed from the
`else` branch above.

The code quoted by Bjoern in comment #7 from nvidia-drm-freebsd-lkpi.c is only
running on FreeBSD before version 13.x. That same devfn value was set like
this:

    pdev->devfn = PCI_DEVFN(pci_get_slot(dev), pci_get_function(dev));

It would be interesting to get the device tree on a working system with:

    devinfo -v

With a DRM device, we have one extra level in the tree (drmn). Here is an
example from my laptop:

    ...
    pci0<ACPI PCI bus>
      hostb0<Host to PCI bridge> pnpinfo vendor=0x8086 device=0x4621
subvendor=0xf111 subdevice=0x0002 class=0x060000 at slot=0 function=0
dbsf=pci0:0:0:0 handle=\_SB_.PC00.MC__
      vgapci0<VGA-compatible display> pnpinfo vendor=0x8086 device=0x46a6
subvendor=0xf111 subdevice=0x0002 class=0x030000 at slot=2 function=0
dbsf=pci0:0:2:0 handle=\_SB_.PC00.GFX0
        drmn0<drmn>
          drm129
          lkpi_iic9<LinuxKPI I2C>
            iicbus12<Philips I2C bus>
              iic12<I2C generic I/O> at addr=0
    ...

-- 
You are receiving this mail because:
You are the assignee for the bug.