BIOS detects 4 GB RAM, but kernel does not
in [General Linux]
|
Prev: Create Linux FC SAN Target
Next: top - high load
From: iforone on 28 Jul 2006 14:45 ravibt(a)gmail.com wrote: > > What's ther output of; > > > > ~$ grep CONFIG_HIGH /boot/config-2.6.9-22.ELsmp > > Nothing. Understood -- I realize now (finally) if you compiled the kernel (for Debian) the place to grep would be most likely in '/usr/src/linux-config2.6.9-22.ELsmp' (or similar). Hrmmm, one the major reasons behind 64bit/EM64T/x86_64 (and even the 64bit instructions that are native only to Itaniums, which is not backwards compatible with 32bit) in the 1st place is to eliminate that 4GB RAM barrier ... so what gives ? Except: maybe perhaps as General S says: you'll need a newer kernel (above 2.6.15). I understand you're running CentOS4.3 Final -- which is basically the free version of RHEL ..yes? > Browsed through the 'Kconfig' files in the src tree and found that > HIGHMEM* options are available for i386 arch only, and in this case > x86_64 is being used. see why above (mostly)... That doesn't necessarily mean that some kind of certain 'config' doesn't need to be compiled into the kernel. Yet I'm not sure exactly which options are necessary, if any, nor am I sure you can achieve your goal using what *seems* (Robert Hancock's reponses) to be essentially an Intel DualCore 32bit CPU(s). I'm having a bit of trouble understanding (or believing) that an EM64T system isn't capable of seeing more than 4GB RAM (although the Mobo max for that Desktop mobo is 4GB) -- BUT then again, that is not a Server grade Mobo either -- it's a Desktop mobo (perhaps using an unsupporting(cheaper) Chipset(?). Yet; the BIOS detects all 4GB (which shoots down my chipset theory) - so maybe it's a kerenl specific issue (harkens back to General S's response about 2.6.15+ kernels only). In my earlier post, I hadn't realized you were using a 64bit kernel. > As an aside, we have another similar dual core intel pentium4 machine > with one difference: 32 bit instead of 64 bit with the same problem: > BIOS detects 4 GB RAM but kernel reports ~3.1GB. In this one, `grep > HIGHMEM /boot/config-2.6.17.7_20060727` (Note: different kernel) gives > the following output: > # CONFIG_NOHIGHMEM is not set > CONFIG_HIGHMEM4G=y > # CONFIG_HIGHMEM64G is not set > CONFIG_HIGHMEM=y > CONFIG_DEBUG_HIGHMEM=y > [This 32 bit machine had reported ~3.1GB RAM with kernel 2.6.9-34.ELsmp > (CentOS 4.3 Final) too.] Since this *other* PC is running a 32bit kernel(?), try a 'newer-than-2.6.15' kernel on _that_ machine. You _should_ be able to achieve success by recompiling. Though if the Mobo doesn't support it (iomem mapping hole), you may be borked.. :( I'm not sure. So basically you have a Intel Pentium D 8xx series Dual Core CPU (which model) on CentOS 4.3 Final, in a Intel Desktop D915GAV Mobo.... -- and another ("similar") PC with a *P4* (Pentium D == Dual Core) - diff Mobo I presume? s775 ? -- yet many of the 5xx, 6xx and EE series do indeed have EM64T capabilties....and all Pentium Ds (8xx series) should too -- even the 840EE edition. So when you say "only diff is it's 32bit instead of 64" - you must mean the Kernel/OS version. > Also, I tried using a different kernel (2.6.17.1) in the 64 bit machine > with the same result. That's to be expected, IF indeed the 2.6.17.1 kernel you tried was NOT a 64bit kernel -- but try that 2.6.17.1 kernel in the 32bit Intel p4 (PentiumD) machine...the one running a 32bit kernel. > As Robert Hancock has explained, probably nothing can be done about > it!! Perhaps not...I'm not sure -- but maybe Robert and others are. Himself, and some others here, know much more about it than I do atm. I've gotten a bit rusty on my newer hardware knowledge, and am not as well informed about these things as I once was. <(sadly)>. Besides I was following AMD64 tech more closely then anyways. <goes off to review some nice bookmarked articles> http://www.quepublishing.com/articles/printerfriendly.asp?p=404293&rl=1 http://www.quepublishing.com/articles/printerfriendly.asp?p=404294&rl=1 http://www.quepublishing.com/articles/printerfriendly.asp?p=404290&rl=1 <on quick perusal -- realizes why he stopped following the garbage advert terminology (mnemonics/monikers) used by both Intel and AMD disgust me> > Thanks very much both of you for the quick responses! > > regards, > Ravi. Peace ;) Regards
From: General Schvantzkoph on 28 Jul 2006 16:25 On Fri, 28 Jul 2006 11:45:39 -0700, iforone wrote: > > ravibt(a)gmail.com wrote: >> > What's ther output of; >> > >> > ~$ grep CONFIG_HIGH /boot/config-2.6.9-22.ELsmp >> >> Nothing. > > Understood -- I realize now (finally) if you compiled the kernel (for > Debian) the place to grep would be most likely in > '/usr/src/linux-config2.6.9-22.ELsmp' (or similar). Hrmmm, one the > major reasons behind 64bit/EM64T/x86_64 (and even the 64bit > instructions that are native only to Itaniums, which is not backwards > compatible with 32bit) in the 1st place is to eliminate that 4GB RAM > barrier ... so what gives ? Except: maybe perhaps as General S says: > you'll need a newer kernel (above 2.6.15). > > I understand you're running CentOS4.3 Final -- which is basically the > free version of RHEL ..yes? > >> Browsed through the 'Kconfig' files in the src tree and found that >> HIGHMEM* options are available for i386 arch only, and in this case >> x86_64 is being used. > > see why above (mostly)... That doesn't necessarily mean that some kind > of certain 'config' doesn't need to be compiled into the kernel. Yet > I'm not sure exactly which options are necessary, if any, nor am I sure > you can achieve your goal using what *seems* (Robert Hancock's > reponses) to be essentially an Intel DualCore 32bit CPU(s). I'm having > a bit of trouble understanding (or believing) that an EM64T system > isn't capable of seeing more than 4GB RAM (although the Mobo max for > that Desktop mobo is 4GB) -- BUT then again, that is not a Server grade > Mobo either -- it's a Desktop mobo (perhaps using an > unsupporting(cheaper) Chipset(?). Yet; the BIOS detects all 4GB (which > shoots down my chipset theory) - so maybe it's a kerenl specific issue > (harkens back to General S's response about 2.6.15+ kernels only). > In my earlier post, I hadn't realized you were using a 64bit kernel. > >> As an aside, we have another similar dual core intel pentium4 machine >> with one difference: 32 bit instead of 64 bit with the same problem: >> BIOS detects 4 GB RAM but kernel reports ~3.1GB. In this one, `grep >> HIGHMEM /boot/config-2.6.17.7_20060727` (Note: different kernel) gives >> the following output: >> # CONFIG_NOHIGHMEM is not set >> CONFIG_HIGHMEM4G=y >> # CONFIG_HIGHMEM64G is not set >> CONFIG_HIGHMEM=y >> CONFIG_DEBUG_HIGHMEM=y >> [This 32 bit machine had reported ~3.1GB RAM with kernel 2.6.9-34.ELsmp >> (CentOS 4.3 Final) too.] > > Since this *other* PC is running a 32bit kernel(?), try a > 'newer-than-2.6.15' kernel on _that_ machine. You _should_ be able to > achieve success by recompiling. Though if the Mobo doesn't support it > (iomem mapping hole), you may be borked.. :( I'm not sure. > > So basically you have a Intel Pentium D 8xx series Dual Core CPU (which > model) on CentOS 4.3 Final, in a Intel Desktop D915GAV Mobo.... > > -- and another ("similar") PC with a *P4* (Pentium D == Dual Core) - > diff Mobo I presume? s775 ? -- yet many of the 5xx, 6xx and EE series > do indeed have EM64T capabilties....and all Pentium Ds (8xx series) > should too -- even the 840EE edition. So when you say "only diff is > it's 32bit instead of 64" - you must mean the Kernel/OS version. > >> Also, I tried using a different kernel (2.6.17.1) in the 64 bit machine >> with the same result. > > That's to be expected, IF indeed the 2.6.17.1 kernel you tried was NOT > a 64bit kernel -- but try that 2.6.17.1 kernel in the 32bit Intel p4 > (PentiumD) machine...the one running a 32bit kernel. > >> As Robert Hancock has explained, probably nothing can be done about >> it!! > > Perhaps not...I'm not sure -- but maybe Robert and others are. Himself, > and some others here, know much more about it than I do atm. I've > gotten a bit rusty on my newer hardware knowledge, and am not as well > informed about these things as I once was. <(sadly)>. Besides I was > following AMD64 tech more closely then anyways. > > <goes off to review some nice bookmarked articles> > http://www.quepublishing.com/articles/printerfriendly.asp?p=404293&rl=1 > http://www.quepublishing.com/articles/printerfriendly.asp?p=404294&rl=1 > http://www.quepublishing.com/articles/printerfriendly.asp?p=404290&rl=1 > > <on quick perusal -- realizes why he stopped following the garbage > advert terminology > (mnemonics/monikers) used by both Intel and AMD disgust me> > >> Thanks very much both of you for the quick responses! >> >> regards, >> Ravi. > > Peace ;) > > Regards It's not just a kernel issue, it's a BIOS + kernel issue. The BIOS controls the physical mapping of the RAM and the IO space. The BIOS should have a feature that does memory hole remapping. The kernel code that handles this is the IOMMU code which is broken in 2.6.14 (causing the system to crash on boot if memory hole remapping is enabled). It works in 2.6.13 and in 2.6.15, 2.6.16 and 2.6.17. I doubt it existed in 2.6.9 which is very old.
From: iforone on 28 Jul 2006 23:40 General Schvantzkoph wrote: > On Fri, 28 Jul 2006 11:45:39 -0700, iforone wrote: > > > > > ravibt(a)gmail.com wrote: > >> > What's ther output of; > >> > > >> > ~$ grep CONFIG_HIGH /boot/config-2.6.9-22.ELsmp > >> > >> Nothing. > > > > Understood -- I realize now (finally) if you compiled the kernel (for > > Debian) the place to grep would be most likely in > > '/usr/src/linux-config2.6.9-22.ELsmp' (or similar). Hrmmm, one the > > major reasons behind 64bit/EM64T/x86_64 (and even the 64bit > > instructions that are native only to Itaniums, which is not backwards [snip] > It's not just a kernel issue, it's a BIOS + kernel issue. The BIOS > controls the physical mapping of the RAM and the IO space. The BIOS should > have a feature that does memory hole remapping. The kernel code that > handles this is the IOMMU code which is broken in 2.6.14 (causing the > system to crash on boot if memory hole remapping is enabled). It works in > 2.6.13 and in 2.6.15, 2.6.16 and 2.6.17. I doubt it existed in 2.6.9 which > is very old. Thanks very much for your reply and explanation -- I guess (see my recent reply to Robert Hancock's follow-up to me) it has to do with BIOS + Kernel + Chipset + Intel Design (MemController):: Yet for AMD64 it only involves BIOS + Kernel... Thansk for any continuing remarks -- I feel like I'm getting caught up to date on my hardware stuff ... I appreciate the responses. [ not really important ] What, if anything, can you tell me(us) about how XP x64 accesses / uses larger than 4GB RAM (on Intel Mobos: Desktop / Server and their Chipsets) -- if it actually even can. I'm aware of PAE, but haven't remembered the specifics...Thanks again [ /not really important ] Regards
From: Aragorn on 29 Jul 2006 11:19
On Saturday 29 July 2006 05:40, iforone stood up and spoke the following words to the masses in /comp.os.linux.misc...:/ > What, if anything, can you tell me(us) about how XP x64 accesses / > uses larger than 4GB RAM (on Intel Mobos: Desktop / Server and their > Chipsets) -- if it actually even can. I'm aware of PAE, but haven't > remembered the specifics...Thanks again Well, the maximum amount of physical memory accessible via 32-bit addressing is 4 GB. This is why all /x86/ CPU's from the Pentium Pro on also have a PAE mode, which allows for 36-bit addressing in a paged mode, i.e. only 4 GB can be accessed at the same time - 3 GB for each process with the normal 1 GB/3 GB split - but a total physical memory capacity of 64 GB can be used. PAE mode only applies to a 32-bit operating system, i.e. if an /x86-64/ CPU is runnning in 32-bit mode. You don't need PAE if the /x86-64/ CPU runs in native 64-bit mode as the memory address capabilities are then far higher already. I have my own kernel compiled with PAE support because PAE also allows the implementation of an /NX/ bit - i.e. the no-execute bit - on memory pages in 32-bit machines. 32-bit /x86/ CPU's don't have an /NX/ bit in hardware, but if the CPU runs in PAE, the Linux kernel can emulate /NX/ via software. My system is a dual 32-bit Xeon 2.2 GHz with hyperthreading and 4 GB of physical RAM installed, by the way. -- With kind regards, *Aragorn* (Registered GNU/Linux user #223157) |