On 12.02.2009 00:19, Stefan Reinauer wrote:
On 11.02.2009 18:11 Uhr, ron minnich wrote:
I agree it's an emergency however :-)
10 minute boot times! call the hospital, the computer is sick!
Heh. :-D
I did a very similar patch two days ago. Sorry this is not against Carl-Daniel's latest changes, but I thought I'd put it out for discussion first.
No problem. Two patches are better than no patch.
There's one case when MTRR setup goes severely wrong, and that is all those boards with UMA graphics onboard. That's all the 945GM boards, the 690 boards, some VIA boards, etc etc.
What the patch does is create a special case for UMA. It checks whether there's an MTRR hole, and if there is none, it creates one for the UMA area.
With the patch applied my test board went down from 8 used MTRRs to 2 (one for RAM and one for UMA) and at the same time the complete RAM is covered.
I remember there was a suggestion for a complete "optimal" MTRR setup algorithm that attempts to always do the right thing with major complexity. This patch is much simpler. It takes the most common case and fixes it without trying to be perfect. So I think this is a good solution for v2, and maybe someone wants to do the perfect thing for v3 at some point.
Comments? Acks?
The patch has three parts: - Reduction of BIOS MTRRs from 8 to 6. Looks fine to me. I actually have that in my tree as well. Ack. - Verbose complaining if we run out of MTRRs. A variant of this has already been committed, but we may want to use your detailed message. Good. - UMA MTRR hole special case. AFAICS your algorithm won't help for any board with uncached SMM memory before UMA. One example that comes to mind is the VIA board where the problems were noticed first. Sorry.
I'll look into creating a simplified version of my algorithm which should be free of special cases and still understandable.
Regards, Carl-Daniel