Re: [discuss] Re: 2.6.19-rc4: known unfixed regressions (v3)

[Linus Torvalds]

On Wed, 8 Nov 2006, Linus Torvalds wrote:
>
> And pci_mmcfg_init() will refuse to even use MMCONFIG unless either the 
> direct probe failed _or_ the MMCONFIG area is marked entirely reserved 
> in the e820 tables. Exactly because MMCONFIG generally doesn't _work_.

Ahh. I see the bug now.

When we check whether MMCONFIG is ok, we do this:

	if (type == 1 && !e820_all_mapped(pci_mmcfg_config[0].base_address,
			pci_mmcfg_config[0].base_address + MMCONFIG_APER_MIN,
                        E820_RESERVED)) {

ie we check whether there is room for MMCONFIG_APER_MIN reserved things.

We then _reserve_ a totally different region in 
pci_mmcfg_insert_resources(), because we use a totally different range.

What a piece of crap. 

Andi, I'm getting really upset about this kind of thing. You've been very 
much not careful about MMCFG in general, and are allowing total crap to go 
into the kernel, without any thought. Just "testing" something isn't good 
enough, it needs to be thought out.

I'm going to revert that totally bogus commit that added that broken 
"pci_mmcfg_insert_resources()" function. It could be done right, but doing 
it right would require that the function 

 - be called _before_ deciding to use MMCFG 
 - return an error number if it couldn't allocate the things
 - check that the region was reserved

and then if some reservation failed, we shouldn't use MMCONFIG in the 
first place. 

We really should stop using MMCONFIG entirely, until we have a 
per-southbridge true knowledge of what the real decoding is. The BIOS 
tables for this are simply too damn unreliable.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/