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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
