Incorrect RAM detected in Linux

[civad]

First of all, I tried searching the posts but I could not find anything relevant.

So here goes:

I have 1024 MB DDR (PC2100) installed on my system: 2x256 MB + 1x 512 MB. The BIOS detects it fine, so does Win 2000.
But under Debian, I see that the system detects only 896 MB. Any ideas as to why its happening that way?

(I think since the BIOS and the 'other' OS detects the memory ok, its not a HW problem, hence I am not giving details of the HW)

I am running Sarge (Debian testing) Kernel 2.4.21.

Cheers,

Civ

 

[CTho9305]

try passing mem=1024 as a boot parameter and see what happens.

 

[civad]

Tried doing that: the system hangs up at "uncompressing kernel" at boot time.

Maybe I am missing something???

 

[Abzstrak]

when passing that you should always do 1MB less (Well, relaly 640k, but round up to 1MB)... try passing it 1023 instead and see what happens...

 

[Jonitus]

Had a similar problem a while back. Don't know for sure, but it seemed to me that 1024MB was the cutoff point for Linux's "himem" support for the kernel. I had to recompile the kernel to get it to see and use more than 768MB of my ram. Maybe it helps, maybe it don't.

 

[pitupepito2000]

Originally posted by: Jonitus
Had a similar problem a while back. Don't know for sure, but it seemed to me that 1024MB was the cutoff point for Linux's "himem" support for the kernel. I had to recompile the kernel to get it to see and use more than 768MB of my ram. Maybe it helps, maybe it don't.

I agree with Jonitus, I was reading the other day that if you plan to have more than 960 MB of memory you have to compile High memory support in your kernel. Here is how to do it:
1. open shell
2. su (enter root password when prompted)
3. cd /usr/src/linux
4. make menuconfig
5. Go to "Processor Type and features"
6. enable "High Memory Support"
7. make dep
8. make bzImage
9. make modules
10. make modules_install
11. cp arch/i386/boot/bzImage /boot/vmlinuz
12. cp System.map /boot
13. update lilo.conf and run lilo

I hope this helps,
pitupepito

 

[civad]

THanks guys, I did recompile the kernel. But for some reason I am still haveing the problem.

I'm looking for the solution myself. Will get back if I find something.!

Cheers,

Civ

 

[Need4Speed]

memmap=exactmap mem=640k@0 mem=1023@1M

pass that to the kernel when you boot it

then edit lilo or grub accordingly to recognize it during each boot

 

[pitupepito2000]

Originally posted by: civad
THanks guys, I did recompile the kernel. But for some reason I am still haveing the problem.

I'm looking for the solution myself. Will get back if I find something.!

Cheers,

Civ

Did you update lilo and run lilo again, it could be that lilo is still loading the old kernel

 

[civad]

pitupepito2000, No lilo, but grub

Yeah, I DID update grub, but no avail.

Need4Speed, I will give your method a try when I get back home in the evening.

Thnx again

 

[Abzstrak]

uhm, there is nothing to update in grub, just change the grub.conf (or menu.lst depending on the versino of grub) and reboot.... it doesn't require updating the way lilo does

 

[civad]

Recompiling the kernel ( for the nth time ) to 4 GB mem. seemed to work.
$ free
total
Mem: 1032660


Thanks all!

 

[kylef]

Man, I didn't realize there was a distro out there running a kernel with less than 1 gig of physical RAM support compiled in by default. Is this Debian-specific? I never had this problem with stock RedHat kernels or FreeBSD, for that matter...

 

[Chaotic42]

Originally posted by: kylef
Man, I didn't realize there was a distro out there running a kernel with less than 1 gig of physical RAM support compiled in by default. Is this Debian-specific? I never had this problem with stock RedHat kernels or FreeBSD, for that matter...

Depends on what he's using. My Debian 2.2r1 CDs come with 2.2.19 with <960MB and no SMP. I tried booting with less than that with 4GB support enabled, and it wouldn't boot.

 

[Nothinman]

I never had this problem with stock RedHat kernels or FreeBSD, for that matter...

There is like 3 'stock' RH kernels, it installs the HIGHMEM enabled ones if it sees your box needs it. As for FreeBSD, I don't know.

 

[kylef]

I guess the question is, why NOT enable high memory support in the kernel? Surely the overhead is pretty small? I'm guessing it would involve increasing the amount of page table infrastructure the kernel would have to maintain, but that it would have little or no noticeable impact on performance.

In my experience, distros are usually good about including generic support for all kinds of different systems in their stock kernels. After all, the vast majority of users don't recompile their own kernel. Surely it is a mistake to install a kernel that requires a recompile if >=1GB of RAM is ever installed on the machine?

I'm guessing there are probably people fighting to keep any bloat whatsoever out of the kernel so that it will boot on ancient hardware with tiny amounts of RAM. But when doing that sacrifices mainstream support for newer systems, what have you really won?

 

[Nothinman]

I guess the question is, why NOT enable high memory support in the kernel? Surely the overhead is pretty small? I'm guessing it would involve increasing the amount of page table infrastructure the kernel would have to maintain, but that it would have little or no noticeable impact on performance.

It only allocates page tables for memory that it finds at runtime so that wouldn't be the problem, otherwise the 64G option would be unsuable for anyone because it would need to allocate something like 8G for page tables. I can't remember the exact number but basically if you have 64G memory you can't boot Linux properly with the 64G option enabled yet because it uses up all the low memory for page tables and a ton of things, like 32-bit DMA, don't work on high memory.

Surely it is a mistake to install a kernel that requires a recompile if >=1GB of RAM is ever installed on the machine?

Depends on how you look at it. Debian isn't catering to the same users that RH is, if Debian requires a kernel recompile to use >893M or >4G memory I don't see it as that big of a deal.

I'm guessing there are probably people fighting to keep any bloat whatsoever out of the kernel so that it will boot on ancient hardware with tiny amounts of RAM. But when doing that sacrifices mainstream support for newer systems, what have you really won?

But if you start giving in to things like making HIGHMEM support the default then other things creep in, like how about making support for large block devices the default even though most people don't have volumes larger than 2TB yet. And somethings just don't work well with HIGHMEM yet, I know for a fact that swsusp doesn't work with HIGHMEM yet (it yelled at me when I tried it on my notebook which has 1G memory), so which is more important to you the amount of memory available or the ability to hibernate to a swap partition? You're answer might not be the same as mine so now we've got two mutually exclusive features that aren't detectable by an installation routine and then other people consider it bad if you ask technical questions like that because it confuses people.

 

[kylef]

And somethings just don't work well with HIGHMEM yet, I know for a fact that swsusp doesn't work with HIGHMEM yet (it yelled at me when I tried it on my notebook which has 1G memory),

Ah, I didn't know about such problems. That would be good enough reason for me to leave it out of my distribution, I suppose. But I would start yelling to get that stuff fixed, considering that systems with 1 gig of RAM are getting fairly common (more common than >1TB disk arrays).

 

[Nothinman]

But I would start yelling to get that stuff fixed, considering that systems with 1 gig of RAM are getting fairly common (more common than >1TB disk arrays).

I agree, the message it gives suggests sending the swsusp maintainer 1G of memory so he can debug it, which I am seriously considering =)