Hello,
Actually, I forgot to ask in my last email... I could not understand why
BUG() was there.., On my system I was running into that code, and couldnt
understand why it was happening, so yes, we should put it back when we
figure out why we are hitting that code. Any advance pointers will help me
debug.
Also you are right that it will crash if someone specifies mem=512M when the
BIOS actually put the tables in say 2GB range. How do we solve this?
Best Wishes,
Lyle
>From: "Manfred Spraul" <manfreds@colorfullife.com>
>To: "Lyle Coder" <x_coder@hotmail.com>, "Ingo Molnar"
><mingo@chiara.csoma.elte.hu>, <linux-kernel@vger.rutgers.edu>
>CC: "Stephen C. Tweedie" <sct@redhat.com>
>Subject: Re: HIGH MEMORY access
>Date: Tue, 11 Apr 2000 00:09:33 +0200
>
>From: "Lyle Coder" <x_coder@hotmail.com>
> > Ingo,
> > Please accept this patch as I am able to boot on machines that place the
>MPS
> > tables above 1GB with this patch.
> >
>
>Are the changes to highmem.c really required, or are they remainders from
>debugging?
>I don't understand why you removed the BUG() calls.
>
>And I don't like that kmap() is abused for the MP table:
>* What happens when you boot with
> mem=512M
> on the lilo command line?
>I assume it will crash.
>
>* What happens when someone boots a non-highmem kernel?
>e.g. an IO apic enabled UP emergency boot disk?
>
>I'll try to implement vmap_boot(long long addr, len) tomorrow, but
>obviously
>your patch is better than the current code.
>
>--
> Manfred
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:15 EST