Created attachment 162561 [details] kern.log Hi, I've just fitted an Nvidia 750 gtx to a mac pro 2006 1.1, and the card is not being detected in the 4 lane 16x pcie slot 1, although it is detected in slot 2 and 3 although at 16x only with only 1 lane, so it has really low bandwidth. In a recent bug report https://bugzilla.kernel.org/show_bug.cgi?id=85491 the can't claim Bar 0 is reported as causing a problem for a Radeon card, a patch is submitted and it seems a bisect revealed a kernel patch issue. As this is an NVidia card (on the proprietary driver) I am submitting this as a separate bug report, also kernel.log reports that : PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug The kernel only detects that it can't claim Bar 0 when I put the above grub paramater on the boot line. In either case, the machine detects my old Nvidia GTX 8800 with no problem. In the case of both graphic cards they are PC unflashed, not Apple. I note that there is a stack trace listed at the end of each boot which might relate to the Nvidia driver.
Created attachment 162581 [details] lspci -vvn output
I'm going to attempt to debug this myself, as I'm reasonably capable of reading code and know how to add debug symbols etc. I don't (as yet) know how to make patches with diff, but I'll probably work it out. There is a patch suggested in bug 85941, which I'm going to start with as an entry point into understanding the code, along with the effect of the grub commandline parameter pci=use_crs. If I find anything of any use I'll post it here.
https://bugzilla.kernel.org/show_bug.cgi?id=85491 - the above comment's bug listing leads to the wrong bug.
If you have any advice or suggestions, I'd be very grateful. Many thanks.
BIOS does not allocate that bar in parent range at all. and with pci=use_crs and pci=realloc, all bar get assigned resources. the trace is not related to pci. should be driver problem?
This message: PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug is normal. By default, we ignore ACPI host bridge information if the BIOS date is older than 2008 (see pci_acpi_crs_quirks()). You can override that default by booting with "pci=use_crs". On your system, that results in: Command line: ... pci=use_crs ... pci_bus 0000:00: root bus resource [mem 0x80000000-0xfe000000] pci 0000:00:08.0: can't claim BAR 0 [mem 0xfe700000-0xfe7003ff 64bit]: no compatible bridge window pci 0000:00:08.0: BAR 0: assigned [mem 0x80e00000-0x80e003ff 64bit] The "no compatible bridge window" message means that 0xfe700000 isn't inside the host bridge window of [mem 0x80000000-0xfe000000], so we have to assume that accesses to 0xfe700000 will not reach the device. Therefore, Linux reassigns BAR 0 to be at [mem 0x80e00000-0x80e003ff] instead. This apparently works fine. This warning: WARNING: CPU: 0 PID: 2125 at drivers/gpu/drm/drm_ioctl.c:143 drm_setversion+0x17e/0x190 [drm]() No drm_driver.set_busid() implementation provided by nv_drm_driver [nvidia]. Use drm_dev_set_unique() to set the unique name explicitly. is unrelated to the BAR 0 messages above and is not a PCI issue. That looks like something related to the proprietary Nvidia driver. Since we can't fix that, I'm closing this as invalid.