I'm sorry I haven't been able to follow up on this issue yet. Is there still something that isn't working right? If so, please open a report at http://bugzilla.kernel.org (Drivers/PCI component) and CC me. I'm still hoping to take a look at your dmesg log and see if we can improve the kernel output, but I haven't had a chance to work on it yet. Bjorn On Fri, Jul 1, 2011 at 7:48 PM, Sagar Borikar <sagar.borikar@xxxxxxxxx> wrote: > Attaching the dmesg output. Kindly pardon me for flooding the log with > my prints which I used for debugging. > > Thanks > Sagar > > On Sat, Jul 2, 2011 at 1:05 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> On Fri, Jul 1, 2011 at 10:24 AM, Sagar Borikar <sagar.borikar@xxxxxxxxx> wrote: >>> Actually I don't get any prints related to non-detected buses. But I >>> see that the bus number is skipped for those devices. Tried to debug >>> in the kernel by inserting prints in the pci scan path but I don't >>> even see that bus is getting created. Is it dependent on the bios >>> order? Looks like bios skips the device which is immediately after the >>> ari capable device. I also don't see any failure message in the >>> dmesg. The problem is parented_bus scan as well individual single >>> device bus scan / pci slot scan is not failing. This is x86 based >>> server >>> >>> lspci output is: >>> 08:00.0 >>> 0a:00.0 >>> 0c:00.0 >>> 0e:00.0 >>> >>> I can post the dmesg output with the explicitly added prints. >> >> Please do. Maybe we can use this to improve what we put in dmesg. >> >>> Is the scanning of the bus depends upon what bios exposes to the OS? >> >> The architected way is for the OS to use ACPI to discover PCI host >> bridges, then use native PCI enumeration below each host bridge. >> >> Bjorn >> > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
