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

[Linus Torvalds <torvalds@linux-foundation.org>]

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.

Now, the thing that worries me a bit is that I wonder how common this kind 
of crap is. And in particular, I wonder how often we've been saved from 
horrible issues like this by the fact that we've inserted the e820 
resources first. Of course - it can work both ways - sometimes it saves 
us, and sometimes it just causes more problems (eg when we then 
re-allocate the resource successfully somewhere else).

		Linus