Hello,
I have a problem with high ram support on 2.4.7 to 2.4.17 all behave the
same. I have a quad Xeon 700 box with 16gb of ram on an Intel SKA4 board.
The ram is all the same 16 1gb PC100 SDRAM modules from Crucial. If I
compile the kernel with high ram (64gb) support, my system runs very slow,
it takes about 15 minutes for make menuconfig to come up. If I recompile
the kernel with 4gb support, it runs perfectly normal and very fast, but I
have 12 gigs that I can't use. Is this a known issue? Is there a fix? I
tried just about everything and I am all out of options. Please help!
Thanks.
---------------------
Eugene Chupkin
Systems Engineer
Credit.Com, Inc.
[email protected]
Tel.(510)545-1006
Fax.(510)748-3715
> I have a problem with high ram support on 2.4.7 to 2.4.17 all behave the
> same. I have a quad Xeon 700 box with 16gb of ram on an Intel SKA4 board.
> The ram is all the same 16 1gb PC100 SDRAM modules from Crucial. If I
> compile the kernel with high ram (64gb) support, my system runs very slow,
> it takes about 15 minutes for make menuconfig to come up. If I recompile
> the kernel with 4gb support, it runs perfectly normal and very fast, but I
> have 12 gigs that I can't use. Is this a known issue? Is there a fix? I
> tried just about everything and I am all out of options. Please help!
Thats almost certainly indicating that the memory type range registers
were not set up correcly by the BIOS. Check /proc/mtrr and also ask your
vendor about BIOS updates to address the problem
(If there aren't any you can hack around it but its not nice to let vendors
get away with bugs if that indeed is what it is)
Here is the output of /proc/mtrr with the 4gb image
reg00: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
And this is with 64gb image
reg00: base=0xe6000000 (3680MB), size= 32MB: uncachable, count=1
reg01: base=0xe8000000 (3712MB), size= 128MB: uncachable, count=1
reg02: base=0xf0000000 (3840MB), size= 256MB: uncachable, count=1
reg03: base=0x00000000 ( 0MB), size=8192MB: write-back, count=1
reg04: base=0x200000000 (8192MB), size=4096MB: write-back, count=1
reg05: base=0x300000000 (12288MB), size=2048MB: write-back, count=1
reg06: base=0x380000000 (14336MB), size=1024MB: write-back, count=1
reg07: base=0x3c0000000 (15360MB), size= 512MB: write-back, count=1
I'm not sure if that looks right, any ideas?
Thanks
-E
On Wed, 13 Feb 2002, Alan Cox wrote:
> > I have a problem with high ram support on 2.4.7 to 2.4.17 all behave the
> > same. I have a quad Xeon 700 box with 16gb of ram on an Intel SKA4 board.
> > The ram is all the same 16 1gb PC100 SDRAM modules from Crucial. If I
> > compile the kernel with high ram (64gb) support, my system runs very slow,
> > it takes about 15 minutes for make menuconfig to come up. If I recompile
> > the kernel with 4gb support, it runs perfectly normal and very fast, but I
> > have 12 gigs that I can't use. Is this a known issue? Is there a fix? I
> > tried just about everything and I am all out of options. Please help!
>
> Thats almost certainly indicating that the memory type range registers
> were not set up correcly by the BIOS. Check /proc/mtrr and also ask your
> vendor about BIOS updates to address the problem
>
> (If there aren't any you can hack around it but its not nice to let vendors
> get away with bugs if that indeed is what it is)
>
On Feb 13, 2002 02:00 +0000, Alan Cox wrote:
> > I have a problem with high ram support on 2.4.7 to 2.4.17 all behave the
> > same. I have a quad Xeon 700 box with 16gb of ram on an Intel SKA4 board.
> > The ram is all the same 16 1gb PC100 SDRAM modules from Crucial. If I
> > compile the kernel with high ram (64gb) support, my system runs very slow,
> > it takes about 15 minutes for make menuconfig to come up. If I recompile
> > the kernel with 4gb support, it runs perfectly normal and very fast, but I
> > have 12 gigs that I can't use. Is this a known issue? Is there a fix? I
> > tried just about everything and I am all out of options. Please help!
>
> Thats almost certainly indicating that the memory type range registers
> were not set up correcly by the BIOS. Check /proc/mtrr and also ask your
> vendor about BIOS updates to address the problem
The other possibility with that much RAM is that the page tables are taking
up all of the low RAM. Andrea has a patch to put the page tables into
higmem in the recent -aa kernels.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Tue, 12 Feb 2002, Andreas Dilger wrote:
> On Feb 13, 2002 02:00 +0000, Alan Cox wrote:
> > > I have a problem with high ram support on 2.4.7 to 2.4.17 all behave the
> > > same. I have a quad Xeon 700 box with 16gb of ram on an Intel SKA4 board.
> > > The ram is all the same 16 1gb PC100 SDRAM modules from Crucial. If I
> > > compile the kernel with high ram (64gb) support, my system runs very slow,
> > > it takes about 15 minutes for make menuconfig to come up. If I recompile
> > > the kernel with 4gb support, it runs perfectly normal and very fast, but I
> > > have 12 gigs that I can't use. Is this a known issue? Is there a fix? I
> > > tried just about everything and I am all out of options. Please help!
> >
> > Thats almost certainly indicating that the memory type range registers
> > were not set up correcly by the BIOS. Check /proc/mtrr and also ask your
> > vendor about BIOS updates to address the problem
>
> The other possibility with that much RAM is that the page tables are taking
> up all of the low RAM. Andrea has a patch to put the page tables into
> higmem in the recent -aa kernels.
I got it, the 2.4.18pre2aa2/pte-highmem-5 but I can't seem to figure out
what to patch this on, I tried patching it on to 2.2.17, 2.2.18-pre1,
and 2.2.18-pre2. On all those I get a Hunk failed. Any feedback is
appreciated.
-E
On Feb 13, 2002 11:05 -0800, Eugene Chupkin wrote:
> On Tue, 12 Feb 2002, Andreas Dilger wrote:
> > The other possibility with that much RAM is that the page tables are taking
> > up all of the low RAM. Andrea has a patch to put the page tables into
> > higmem in the recent -aa kernels.
>
> I got it, the 2.4.18pre2aa2/pte-highmem-5 but I can't seem to figure out
> what to patch this on, I tried patching it on to 2.2.17, 2.2.18-pre1,
> and 2.2.18-pre2. On all those I get a Hunk failed. Any feedback is
> appreciated.
You may need to use a whole bunch of -aa patches to get it to apply. In
general, the -aa tree is tuned for large machines such as yours, so you
are probably better off getting the whole thing.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Wed, 13 Feb 2002, Andreas Dilger wrote:
> On Feb 13, 2002 11:05 -0800, Eugene Chupkin wrote:
> > On Tue, 12 Feb 2002, Andreas Dilger wrote:
> > > The other possibility with that much RAM is that the page tables are taking
> > > up all of the low RAM. Andrea has a patch to put the page tables into
> > > higmem in the recent -aa kernels.
> >
> > I got it, the 2.4.18pre2aa2/pte-highmem-5 but I can't seem to figure out
> > what to patch this on, I tried patching it on to 2.2.17, 2.2.18-pre1,
> > and 2.2.18-pre2. On all those I get a Hunk failed. Any feedback is
> > appreciated.
>
> You may need to use a whole bunch of -aa patches to get it to apply. In
> general, the -aa tree is tuned for large machines such as yours, so you
> are probably better off getting the whole thing.
>
Whola!!! This fixed my problem. CONFIG_HIGHIO did it. So my kernel is lets
see here... 2.4.18pre2aa2+pte-highmem-5. I hope this will be included in
the 2.4.18 final. Thanks for all your help.
-E
> On Wed, 13 Feb 2002, Andreas Dilger wrote:
> > You may need to use a whole bunch of -aa patches to get it to apply. In
> > general, the -aa tree is tuned for large machines such as yours, so you
> > are probably better off getting the whole thing.
> >
>
On Wed, Feb 13, 2002 at 12:33:37PM -0800, Eugene Chupkin wrote:
> Whola!!! This fixed my problem. CONFIG_HIGHIO did it. So my kernel is lets
> see here... 2.4.18pre2aa2+pte-highmem-5. I hope this will be included in
> the 2.4.18 final. Thanks for all your help.
>
I don't think that will happen. pte-highmem is relatively new code, and
needs more testing before it goes into 2.4. Hugh, and Andrea fixed some
potential problems with it recently, so hopefully most of it is ironed out
now.
Also, Andrea and Marcelo (CCed) need to take some time to merge some of -aa into
2.4-pre. Any comments guys? We're all watching and waiting to see more
merging in this area...
Mike
Hi!
> I have a problem with high ram support on 2.4.7 to 2.4.17 all behave the
> same. I have a quad Xeon 700 box with 16gb of ram on an Intel SKA4 board.
> The ram is all the same 16 1gb PC100 SDRAM modules from Crucial. If I
> compile the kernel with high ram (64gb) support, my system runs very slow,
> it takes about 15 minutes for make menuconfig to come up. If I recompile
> the kernel with 4gb support, it runs perfectly normal and very fast, but I
> have 12 gigs that I can't use. Is this a known issue? Is there a fix? I
> tried just about everything and I am all out of options. Please help!
What happens with 8GB?
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
On Thu, 14 Feb 2002, Pavel Machek wrote:
> Hi!
>
> > I have a problem with high ram support on 2.4.7 to 2.4.17 all behave the
> > same. I have a quad Xeon 700 box with 16gb of ram on an Intel SKA4 board.
> > The ram is all the same 16 1gb PC100 SDRAM modules from Crucial. If I
> > compile the kernel with high ram (64gb) support, my system runs very slow,
> > it takes about 15 minutes for make menuconfig to come up. If I recompile
> > the kernel with 4gb support, it runs perfectly normal and very fast, but I
> > have 12 gigs that I can't use. Is this a known issue? Is there a fix? I
> > tried just about everything and I am all out of options. Please help!
>
> What happens with 8GB?
> Pavel
> --
I didn't test with 8gb since I administrate it remotely, but 16gb is still
having issues with load jumping very high on IO. I think it needs more
work.
-E
On Wed, 13 Feb 2002, Eugene Chupkin wrote:
>
>
> On Wed, 13 Feb 2002, Andreas Dilger wrote:
>
> > On Feb 13, 2002 11:05 -0800, Eugene Chupkin wrote:
> > > On Tue, 12 Feb 2002, Andreas Dilger wrote:
> > > > The other possibility with that much RAM is that the page tables are taking
> > > > up all of the low RAM. Andrea has a patch to put the page tables into
> > > > higmem in the recent -aa kernels.
> > >
> > > I got it, the 2.4.18pre2aa2/pte-highmem-5 but I can't seem to figure out
> > > what to patch this on, I tried patching it on to 2.2.17, 2.2.18-pre1,
> > > and 2.2.18-pre2. On all those I get a Hunk failed. Any feedback is
> > > appreciated.
> >
> > You may need to use a whole bunch of -aa patches to get it to apply. In
> > general, the -aa tree is tuned for large machines such as yours, so you
> > are probably better off getting the whole thing.
> >
>
> Whola!!! This fixed my problem. CONFIG_HIGHIO did it. So my kernel is lets
> see here... 2.4.18pre2aa2+pte-highmem-5. I hope this will be included in
> the 2.4.18 final. Thanks for all your help.
>
I am still having problems even with that kernel, it appears that the
memory that is taken is not given back, after a few hours the load
shoots up, the system gets really slow and then it crashes.. Solutions,
ideas?
Thanks.