On Tue, Jun 10, 2008 at 09:31:58PM +0200, Bernhard Walle wrote: > * Vivek Goyal <vgoyal at 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
