[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Additional RAM brings Lenny to a slow-down



Jochen Schulz wrote:
andy:
Jochen Schulz wrote:
My question is: are there any known limits on the amount of RAM Lenny can operate with?
No, but I think you have hit a problem Linux has with certain mainboards
that I have read about a few times already. I don't know the exact
solution anymore but it involves telling the kernel how much memory you
have. It's something like a 'mem=XXXXM' boot parameter.
Thanks for that clue Jochen. I am running the 2.6.22-3-686 kernel. Can anyone verify this and what the parameters are that need to be passed to the kernel? Is this likely to require my recompiling the kernel?

I did the googling for you (linux slow boot ram upgrade kernel
parameter):

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/129172

:)

J.
Well spotted Jochen - the parameters I Googled for weren't kicking up anything! So it would appear then that the FSB800 board must be a variant of the reported P35-based motherboard.

For additional info, I have included the output of cat /proc/cpuinfo:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) 4 CPU 3.06GHz
stepping        : 9
cpu MHz         : 3056.741
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl tm2 cid cx16 xtpr lahf_lm
bogomips        : 6120.52
clflush size    : 64

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) 4 CPU 3.06GHz
stepping        : 9
cpu MHz         : 3056.741
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl tm2 cid cx16 xtpr lahf_lm
bogomips        : 6113.44
clflush size    : 64

However, I must confess to this stuff being way over my head!

If this is a hardware fault then as suggested in the Ubuntu bug report you linked to, it appears that the fix was to flash the BIOS and upgrade it with a fix from the manufacturers. The other alternative seems to be the mem=xxx option passed to the kernel. If I use the latter approach, is this something that I can develop a script to do automatically at boot (for example, to run it as part of the GRUB parameters), or is it something that I would have to do manually?

Thanks

A

--

"If they can get you asking the wrong questions, they don't have to worry about the answers." - Thomas Pynchon, "Gravity's Rainbow"


Reply to: