Messages in this thread | | | Date | Tue, 12 Jun 2007 14:38:28 -0700 | From | "Ray Lee" <> | Subject | Re: [PATCH] trim memory not covered by WB MTRRs |
| |
On 6/12/07, Pavel Machek <pavel@ucw.cz> wrote: > > > > On some machines, buggy BIOSes don't properly setup WB MTRRs to > > > > cover all available RAM, meaning the last few megs (or even gigs) > > > > of memory will be marked uncached. Since Linux tends to allocate > > > > from high memory addresses first, this causes the machine to be > > > > unusably slow as soon as the kernel starts really using memory > > > > (i.e. right around init time). > > > > > > > > + if ((highest_addr >> PAGE_SHIFT) != end_pfn) { > > > > + printk(KERN_WARNING "***************\n"); > > > > + printk(KERN_WARNING "**** WARNING: likely BIOS bug\n"); > > > > + printk(KERN_WARNING "**** MTRRs don't cover all of " > > > > + "memory, trimmed %ld pages\n", end_pfn - > > > > + (highest_addr >> PAGE_SHIFT)); > > > > + printk(KERN_WARNING "***************\n"); > > > > + end_pfn = highest_addr >> PAGE_SHIFT; > > > > > > Missing 4K of memory is not worth 4K of junk in syslog per boot. Can > > > you drop the stars and stop shouting? > > > > How missing about 1G of memory? We already discussed this, and Andi and > > Venki felt that either a panic or a really obnoxious message was the > > way to go... > > Just use panic, then. > Pavel, > who still thinks anyone missing 1GB of ram will not miss > friendly notice in dmesg, even if it goes without 20 stars.
Panicking when it's not necessary is anti-social. If the kernel can continue, then it should, unless it's a correctness issue that may cause data corruption. Given that the kernel can even work around the problem now, throwing a panic is even less warranted.
Ray - 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/
| |