Re: HIGH MEMORY access

[Lyle Coder]

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" <[e-mail]>
>To: "Lyle Coder" <[e-mail]>,        "Ingo Molnar" 
><[e-mail]>,        <[e-mail]>
>CC: "Stephen C. Tweedie" <[e-mail]>
>Subject: Re: HIGH MEMORY access
>Date: Tue, 11 Apr 2000 00:09:33 +0200
>
>From: "Lyle Coder" <[e-mail]>
> > 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