On Mon, Jan 23, 2012 at 10:14 AM, Martin Burnicki <martin.burnicki@xxxxxxxxxxx> wrote: > Bjorn Helgaas wrote: > [...] > >> Here's the 3.1.4 dmesg: >> >> ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f]) >> pci_root PNP0A08:00: host bridge window [io 0xf000-0xffff] >> ... >> ACPI: PCI Root Bridge [BR50] (domain 0000 [bus 80-fb]) >> pci_root PNP0A08:01: host bridge window [io 0xf000-0xffff] >> pci 0000:80:07.0: PCI bridge to [bus 85-85] >> pci 0000:80:07.0: bridge window [io 0xf000-0xffff] >> pci 0000:85:00.0: reg 10: [io 0xfc00-0xfcff] >> pci 0000:80:07.0: address space collision: [io 0xf000-0xffff] >> conflicts with PCI Bus 0000:00 [io 0xf000-0xffff] >> pci 0000:85:00.0: no compatible bridge window for [io 0xfc00-0xfcff] >> >> The BIOS is telling us that [io 0xf000-0xffff] is routed to both root >> buses (00 and 80), which Linux assumes is not possible. > > Hm, so this sounds like a BIOS bug? That was my initial assumption, but appears not to be the case; see below. > However, the strange thing here is that it actually *does* work if an older > kernel is booted which doesn't do these checks, or even if a newer kernel is > booted with "pci=nocrs". The older kernels and newer kernels with "pci=nocrs" ignore the _CRS information (the "host bridge window" lines in dmesg), so they basically just use what the BIOS configured, which works in this case. >> What are the device addresses that work and those that don't work? My >> guess is the working slots might be under PCI0 (buses 00-7f) and the >> broken ones under BR50 (buses 80-fb). Can you collect a dmesg log >> with a working slot, too? > > The card does *not* work in the slots assigned to buses 83, 84, 85, and 86. > > The card *does* work in the slots assigned to buses 02, 03, and 04. Thanks a lot. That confirms my hypothesis that the card works under PCI0 but not under BR50. >> Can you boot with Windows with the card in the same slot (one that >> doesn't work under Linux) and use AIDA64 (free trial version at >> http://www.aida64.com/downloads) to collect a log? This should show >> where Windows puts the device. > > Done. See the attached file aida64-report.htm. The report has been generated > with the default setting for a hardware report in Aida64. Windows shows the [io 0xf000-0xffff] range as being available under both host bridges, and the fact that those ports actually work under both bridges means they must actually be routed both places. It may be that Linux is being overly strict in rejecting that overlap. I'm not sure what would break if we changed that. Linux has a very hierarchical idea of resources and doesn't have a mechanism for managing duplicates like that. I'll add this info to the bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=42606) if you haven't already. 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
