On Sun, 13 Apr 2008 11:39:10 +0200
Andi Kleen <andi@firstfloor.org> wrote:

quoted text
> Ingo Molnar <mingo@elte.hu> writes:
> 
> This whole problem just shows that it was a mistake in the first place
> to try to redo the BIOS work in Linux. If BIOS doesn't supply MCFG
> Linux trying to create one (or in general having generalized resource
> allocation) is just a big mess and will cause endless problems.  The
> standard resource code is just not up to the task and it needs very
> intimate knowledge of the hardware that the kernel shouldn't have.
> 
> Again the real fix I think is to just drop all that code in git-x86
> again and finally fix LinuxBIOS to do its job properly and pass a
> proper MCFG (or just forget about using mmconfig with LinuxBIOS - it
> is not that Type1 suddently doesn't work anymore). Then this code
> wouldn't be needed at all

I totally agree with this. MCFG has been EXTREMELY fragile for the last years,
and I don't see that changing anytime soon.
The only thing that works for Linux so far is "if it even smells funny, don't use it".
Smelling funny is things like
1a) Bios table and e820 not matching up, or
1b) Bios table and hardware data not matching up
2) The content not matching content gotten via the traditional method
3) ... (bunch of other sanity checks)

I guess we really need to have
0) If it's not present in the BIOS do not touch
as rule as well.


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/