On Fri, 2010-05-07 at 19:09 -0400, David H. Lynch Jr. wrote: > [ 0.296248] pci 0000:06:00.0: no compatible bridge window for [mem > 0xd2100000-0xd2100fff] > This is the message that sidetracked me. If it is meaningless - fine. > But it was the first of only two messages displayed to the screen > when the system hung. Ooh, sorry, I missed that when I looked through your dmesg log. It's definitely not meaningless, and we use KERN_ERR to print it, which explains why it made it to the screen. Let's see... we reach bus 06 via this bridge, which the BIOS left disabled: pci 0000:00:1c.2: PCI bridge to [bus 06-06] pci 0000:00:1c.2: bridge window [io 0x0000-0x0000] (disabled) pci 0000:00:1c.2: bridge window [mem 0x00000000-0x000fffff] (disabled) pci 0000:00:1c.2: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) Even though the bridge windows are all disabled, the BIOS put the 06:00.0 device here: pci 0000:06:00.0: reg 10: [mem 0xd2100000-0xd2100fff] I think this is probably a BIOS defect, but it's fairly benign. We do go ahead and enable the bridge MMIO window: pci 0000:00:1c.2: PCI bridge to [bus 06-06] pci 0000:00:1c.2: bridge window [io 0x6000-0x6fff] pci 0000:00:1c.2: bridge window [mem 0x44800000-0x449fffff] pci 0000:00:1c.2: bridge window [mem 0x44a00000-0x44bfffff 64bit pref] (In this case, we only need the MMIO window; we don't need the IO or prefetchable MMIO windows, and I don't really know why we enabled them.) Anyway, we then reassigned the 06:00.0 BAR to be inside that MMIO window: pci 0000:06:00.0: BAR 0: assigned [mem 0x44800000-0x44800fff] And everything appears to work as it should. (I assume, anyway; there are wifi messages about the link not being ready, but I would expect more serious messages if the PCI side of things weren't working correctly.) We might consider downgrading the severity of the "no compatible bridge window" message, since there's no need to alarm the user if we can fix it in Linux. But it has been KERN_ERR for several releases, so at least it's not a regression. > The other was about mounting the root filesystem I made the mistake > of assuming they were related - the root filesystem would not mount > because a PCI card or bridge was not setup correctly - say maybe the > disk controller. Right -- certainly a reasonable assumption if those are the only messages you see :-) > If this is a serious problem and not unique to wireless-testing I > will be happy to help trace it down and kill it. > I will try pulling > http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > and building the latest for my system, but I can not do that until > tomorrow. Don't worry about trying Linus' tree. I'm sure it will work exactly the same in this regard. Let me just think about that message a bit. I think it'd be better if we only complained with KERN_ERR after we've tried and failed to allocate resources to a device. Thanks again for your report -- this is the sort of thing that will confuse users even if things actually work correctly, so we can make the experience a little more pleasant by handling this better. 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
