Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

Rafael J. Wysocki
2008-08-30T19:16:38Z

On Saturday, 30 of August 2008, Linus Torvalds wrote:
>
> On Sat, 30 Aug 2008, Rafael J. Wysocki wrote:
> >
> > > And if you have the whole dmesg, that would be useful.
> >
> > dmesg from -rc5 with the offending commit reverted and with the patch
> > below applied is at:
> >
> > http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/2.6.27-rc5-git.log
>
> Ok, the more I look at this, the more interesting it gets.
>
> In particular, this:
>
> ...
> ACPI: bus type pnp registered
> pnp 00:08: mem resource (0xfec00000-0xfec00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp 00:08: mem resource (0xfee00000-0xfee00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp 00:09: mem resource (0xffb80000-0xffbfffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp 00:09: mem resource (0xfff00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp 00:0b: mem resource (0xe0000000-0xefffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp 00:0c: mem resource (0xfec00000-0xffffffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling
> pnp: PnP ACPI: found 13 devices
> ACPI: ACPI bus type pnp unregistered
> SCSI subsystem initialized
> libata version 3.00 loaded.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> PCI: Using ACPI for IRQ routing
> pci 0000:00:00.0: BAR 3: can't allocate resource
> ...
>
> there's a few things to note here:
>
> - the resource at 0000:00:00.0 BAR 3 is totally bogus.
>
> We know it's totally bogus because you actually have other resources in
> the 0xf....... range, and they work fine. It's also likely to be
> totally bogus because it so happens that the end-point of 0xffffffff is
> commonly something that the BIOS leaves as a "I sized this resource",
> because that's how resources are sized (you write all ones into them
> and look what you can read back).
>
> But your lspci -vxx output clearly shows that (a) MEM is enabled in
> the command word, and yes, the BAR register at 0x18 does indeed have
> value 0xe0000000. So it's just the length that is really bogus.
>
> - pnp clearly sees that bogus resource at 0xe0000000-0xffffffff
>
> - BUT: the "can't allocate resource" thing is from
> pcibios_allocate_resources(), and means that the request_resource()
> failed _despite_ the fact that you hadn't reserved the e820 resources
> yet with the new patch.
>
> The thing that seems to save you is that we've already allocated something
> in that region. There's a few things there, like:
>
> fee00000-fee00fff : Local APIC
>
> but that particular one is actually reserved much later, so that doesn't
> explain it. I think that what happens is that we have allocated the _bus_
> resources earlier in "pcibios_allocate_bus_resources()", and that means
> that we already have these resources:
>
> fe700000-fe7fffff : PCI Bus 0000:01
> fe800000-fe8fffff : PCI Bus 0000:02
> fe900000-fe9fffff : PCI Bus 0000:03
> fea00000-feafffff : PCI Bus 0000:04
> feb00000-febfffff : PCI Bus 0000:05
>
> in the resource tree, and that in turn means that when we try to allocate
> the bogus MCFG resource, it fails.
>
> Which is good - it mustn't succeed.
>
> What _broke_ for you is that the horrible patch that got reverted said
> that "if we recognize this as an MCFG resource, we will _always_ try to
> insert it", so it fundamentally broke the whole resource tree, because it
> force-inserted that totally crap resource.

Well, I thought something like this happened, but I wasn't quite sure about the
exact mechanism. Thanks for the explanation. :-)

Rafael