Most recent kernel where this bug did not occur: New system, so no history Distribution: Fedora Core Devel Hardware Environment: CK804 based mobo (GA-K8N Ultra 9) http://www.giga-byte.com.tw/MotherBoard/Products/Products_GA-K8N%20Ultra-9.htm Software Environment: N/A Problem Description: I've just booted on the last Fedora Devel kernel (2.6.14-1.1635_FC5, based on 2.6.14-git2) and my dmesg is now filled with: pcie_portdrv_probe->Dev has invalid IRQ. Check vendor BIOS messages. Should I worry ? Report it somewhere ? Attaching what info ? A google search shows other motherboards are affected, I don't know if the bug is in the Linux CK804 code or in the reference bios for the CK804 Steps to reproduce: Boot, read dmesg
Created attachment 6446 [details] dmesg
Created attachment 6447 [details] lspci
Still there with new F7 bios and 2.6.14-git6
Also on this CK804 board I get PCI-DMA: Disabling IOMMU. pnp: 00:00: ioport range 0x1000-0x107f could not be reserved pnp: 00:00: ioport range 0x1080-0x10ff has been reserved pnp: 00:00: ioport range 0x1400-0x147f has been reserved pnp: 00:00: ioport range 0x1480-0x14ff could not be reserved pnp: 00:00: ioport range 0x1800-0x187f has been reserved pnp: 00:00: ioport range 0x1880-0x18ff has been reserved
The PCIE devices that are complaining are PCIE bridges: 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)... 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)... 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)... 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)... Unclear if they're supposed to have IRQs. Not sure if it is related, but they also advertise MSI capability. Unclear that this issue is related to ACPI -- maybe a stray printk from the PCI express code? booting this bug to PCI category.
I only put in acpi because the error message mumbled about BIOS. Don't really know where it belongs
The error message indicates that the PCI Express bridges in the system don't have any interrupts assigned to them. This is not a problem since the pcie bridges in this sysem didn't report any capability that requires an interrupt anyway (i.e. they don't support pcie hotplug or advanced error reporting). The pcie code is printing a bogus warning that can be ignored in this case.
Ok, we can clean up those error messages, and will in a bit (Rajesh is working on this area for other cleanups too.) Am closing as this really isn't a bug.
Thanks for the analysis