On 6/12/07, Pavel Machek <[email protected]> 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 [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]
