Re: [PATCH] Implement support for mem command line parameter

[Vivek Goyal <vgoyal@redhat.com>]

On Tue, Jun 10, 2008 at 09:31:58PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <vgoyal@redhat.com> [2008-06-09 23:00]:
> >
> > > Right. I just checked with 2.6.22.5 (openSUSE 10.3 kernel), and
> > > 
> > >   - i386: /proc/iomem contains full memory
> > >   - x86_64: /proc/iomem contains truncated memory
> > > 
> > > After the x86 merge, x86_64 now has the behaviour of i386.
> > >   
> > 
> > Cool. Now atleast behavior across x86 and x86_64 is same.
> 
> After studying the code, well, that was wrong. I tested again:
> 
>  - i386: /proc/iomem contains truncated memory
>  - x86_64: /proc/iomem contains full memroy
> 
> And after the merge, it stays the same, i.e. /proc/iomem in i386 is
> truncated.

:-(

> 
> Sorry for the confusion. :-|
> 
> The question is: Is that "accidentally" or by design. The file
> Documentation/kernel-parameters.txt:
> 
>         [X86-32] Use together with memmap= to avoid physical
>         address space collisions. Without memmap= PCI devices
>         could be placed at addresses belonging to unused RAM.
> 
> implies that it's "by design".
> 

IIUC, does that mean if a system has got 3G of RAM then during normal
boot PCI devices will be mapped at physical addresses higher than 3G.
But if I boo the system with mem=2G, then there are changes that PCI
devices get mapped at physical address between 2G and 3G? 

If yes, what's the issue with that? Anyway kernel will never see RAM
beyond 2G.

So if we make these two arch consistent, that is /proc/iomem does
not see truncated memory even user passes mem= option, hopefully
it works for everybody.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec