On Wednesday 04 November 2009 12:31:04 pm Bjorn Helgaas wrote: > On Wednesday 04 November 2009 10:44:35 am Matthew Wilcox wrote: > > On Wed, Nov 04, 2009 at 10:32:37AM -0700, Bjorn Helgaas wrote: > > > This series doesn't change any behavior; it just makes our messages > > > about PCI resource management a little more consistent and complete. > > > > Could you give a before-and-after sample subset of dmesg? This looks > > good, on its face, I just want to see examples. > > Sure. In the normal case, it's not terribly interesting -- I added some > bridge discovery information and ROM BAR assignment messages, as in the > HP DL380G6 diff below. It's more interesting when we find problems. I'll > try to dig up an example of that, too. I don't have an actual dmesg diff, but here's a hand-edited example from a prototype where the BIOS put non-prefetchable BARs in a prefetchable aperture. It took me quite a while to figure out exactly how Linux handled that, which is part of what prompted this series. --- proto.old +++ proto.new pci 0000:04:00.0: reg 10: [mem 0xbc200000-0xbc3fffff 64bit] pci 0000:04:00.0: reg 20: [mem 0xfc00000000-0xfc01ffffff 64bit] +pci 0000:00:03.0: PCI bridge to [bus 04-04] pci 0000:00:03.0: bridge window [mem 0xbc200000-0xbc9fffff] pci 0000:00:03.0: bridge window [mem 0xfc00000000-0xfc07ffffff 64bit pref] [I'd like to consistently use a BAR number or a register offset, but many of our BAR numbers are made-up, so I haven't really pushed on that yet.] -pci 0000:04:00.0: BAR 4: no parent found for of device [0xfc00000000-0xfc01ffffff] +pci 0000:04:00.0: no compatible bridge window for [mem 0xfc00000000-0xfc01ffffff 64bit] -pci 0000:04:00.0: BAR 4: can't claim [mem 0xfc00000000-0xfc01ffffff 64bit] +pci 0000:04:00.0: can't reserve [mem 0xfc00000000-0xfc01ffffff 64bit] +pci 0000:00:03.0: disabling bridge window [mem 0xfc00000000-0xfc07ffffff pref] to [bus 04-04] (unused) -pci 0000:04:00.0: BAR 4: can't allocate [mem 0xbe000000-0xbc9fffff 64bit] +pci 0000:04:00.0: BAR 4: can't assign mem (size 0x2000000) [The weird range in the old message was caused by allocate_resource() clobbering the resource even though it failed -- fixed by a separate patch.] -pci 0000:00:03.0: PCI bridge, secondary bus 0000:04 +pci 0000:00:03.0: PCI bridge to [bus 04-04] pci 0000:00:03.0: bridge window [io disabled] pci 0000:00:03.0: bridge window [mem 0xbc200000-0xbc9fffff] pci 0000:00:03.0: bridge window [mem pref disabled] -- 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
