Thanks! Can you reassign this to "Drivers/PCI" and set "Regression = yes"? I can't seem to do it myself. Also, the logs look like console logs, which don't include everything in the dmesg log unless you boot with "ignore_loglevel". Can you boot the failing one with "ignore_loglevel"? And maybe attach the "lspci -vv" output? I see two things wrong so far. 1) I think we are reassigning PCI resources when we shouldn't. pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfed8ffff] pci_root PNP0A08:00: host bridge window [mem 0x00000000-0xffffffff] pci_root PNP0A08:00: host bridge window expanded to [mem 0x00000000-0xffffffff]; [mem 0x00000000-0xffffffff] ignored pci 0000:00:1c.1: address space collision: [mem 0xfde00000-0xfdefffff 64bit pref] conflicts with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff] pci 0000:00:1c.2: address space collision: [mem 0xfdf00000-0xfdffffff 64bit pref] conflicts with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff] ... These "collisions" are not actually collisions -- [mem 0xfde00000-0xfdefffff 64bit pref] is a perfectly legal assignment inside the [mem 0xf0000000-0xfed8ffff] host bridge window. The supposed host bridge window [mem 0x00000000-0xffffffff] is clearly bogus, but we don't handle it well in Linux. The kernel resource code doesn't allow overlaps at the same level, so we have a hack that coalesces those overlapping host bridge windows, which leads to these "collisions," which in turn causes unnecessary PCI resource reassignments. 2) The reassignment fails when it shouldn't. It looks like when we fail, we're assigning more space to the 1c.3 and 1c.2 bridge windows than we did before, but beyond that, I think Ram will have more insight than I do right now. -- 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
