>128 MB RAM stability problems (again)

Hi,

you might remember an e-mail from me (two weeks ago) with my problems where linux would not boot up or be highly instable on a machine with 256 MB RAM, while it was 100% stable with 128 MB RAM. Basically, I still have this problem, so I am running with 128 MB RAM again.

I've been running Mandrake 7.2 on another machine for some time - no problem, until..... I added another 64 MB RAM and tried to install redhat (25 times (!!!)) and Mandrake 8.0... Both crash with memory faults..... Redhat just freezes or givesa a python warning, Mandrake gives a segfault with a warning that "memory is missing".... Both refuse to complete installation...

I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in my house with more than 128 MB RAM?!? Can someone please point out to me that he's actually running kernel-2.4.x on a machine with more than 128 MB RAM and that he's NOT having severe stability problems? And can that same person PLEASE point out to me why 2.4.x is crashing on me (or help me to find out...)?

First machine is a Intel P-II 400 with 128 MB RAM (133 MHz SDRAM) and crashing when I insert an additional 128 - it's running RH-7.0 with kernel-2.4.4. Second machine is an AMD Duron 600 with 196 MB RAM (also 133 MHz SDRAM), crashing during the installation of both Mandrake 8.0 and Redhat 7.1 and which used to run stable with 128 MB RAM or 64 MB RAM with Mandrake-7.2. Win2k runs stable on this machine in all configurations.

I'm getting desperate.... win2k is running stable and it's scary to see linux crash while win2k runs stable and smooth.

(ps I'm not subscribed to the list - please CC a copy to me when replying)

Thanks in advance for any help on this,

--
Ronald Bultje

I don't have the answer for your situation, but in answer to one of your questions I can happily enumerate the following boxes I installed, all of which are running 2.4.x kernels on Red Hat 7.1 with excellent stability and performance:

"Name Brand" boxes:
(3) Dell 2450s, Dual P3-1000, 512 MB RAM
(2) HP Netservers, P3-700, 512 MB RAM Compaq 6500, Quad PPro 200, 1 GB RAM

Self built clone boxes:
AMD K6/2 450, 256 MB RAM, low end ASUS mb P3-933, 512 MB RAM, Intel i810 motherboard P3-866, 512 MB RAM, Aopen motherboard
and more -

These boxes either have an uptime dating from the initial 7.1 install (60+ days), or from the last kernel update -

cu

jjs

[...]

It's likely hardware problems. Different OSes excercise the memory subsystems quite differently, so it's possible (and common) to see problems in one OS where another appears to run fine.

Download memtest86 and test your system with 256MB in it -- if it reports any problems, it's definitely hardware.

Charles

-----------------------------------------------------------------------
Charles Cazabon                            <[email protected]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------

Can I suggest you change your memory vendor and/or get an antistatic wrist strap ?

Multiple boxes, all solid with 256Mb

Ditto. One with 320, one with 256 and one with 192. All dual booting Win98 or Win2k and Mandrake 8.0 with 2.4.3.

Scott

----- Original Message -----
From: "Alan Cox" <[email protected]>
To: "Ronald Bultje" <[email protected]>
Cc: "Linux Kernel Mailing List" <[email protected]>
Sent: Wednesday, July 04, 2001 2:29 PM
Subject: Re: >128 MB RAM stability problems (again)

Alan> Can I suggest you change your memory vendor and/or get an Alan> antistatic wrist strap ?

I also have had problems with a machine that had 128Mb + 64 Mb. I discovered the following about 2.4.x. You _should_ have a swap file that is double RAM. Mixing different SDRAM types is probably a bad thing. So if you upgraded, then that might be problematic.

However, when I did have 196 Mb it completely trashed my file system. I also work with electronic components and these were handled in an ESD safe manner. It may be possible to set the SDRAM controller to handle disparate SDRAM chips...but it is probably very painful. I have done this on an MPC860 and a Coldfire chip. However, I haven't the faintest clue about PC controllers.

Perhaps when I am feeling brave again, I will return to try additional memory.

hth,
Bill Pringlemeir.

And here's a counter claim: At home have 128 + 64, both of different speeds and brands. Of course, to run properly you have to force the pc100 to run at 66, but other than that they're happy (96MB swap)

____/|  Ragnar Højland      Freedom - Linux - OpenGL |    Brainbench MVP
\ o.O|  PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming
 =(_)=  "Thou shalt not follow the NULL pointer for  | (www.brainbench.com)
   U     chaos and madness await thee at its end."

Ragnar> And here's a counter claim: At home have 128 + 64, both of Ragnar> different speeds and brands. Of course, to run properly you Ragnar> have to force the pc100 to run at 66, but other than that Ragnar> they're happy (96MB swap)

[...]

Yes, I imagine Linux does work ;-) The fact is that SDRAM is problematic (from a hardware perspective). For the OP, it could be a bus capacitance problem. If the boards are older, they might not be designed for larger memories with have a higher capacitance. Slowing down the accesses will stop the problem. You would do this by going to the BIOS and changing the CAS and RAS timings (or maybe you can change the SDRAM clock). SDRAM has a `NOP' state so that you can run at a higher clock speed, but delay a command. Anyways, I don't think that Linux is messing with the SDRAM controllers, but I am not an authority. Also, a single stick is always better than several smaller memory sizes.

I was looking at the memtest86 web sight "http://www.memtest86.com/" and I didn't see anything that test for SDRAM cache lines. Single beat SDRAM read/writes are less stressful than BURSTS. It is typical for single beats read/write to work while bursts fail as four 32 bit values are written and read in quick succession. The `algorithm' description on the web page doesn't seem to test for this issue from what I see... of course I have been wrong before!

regards,
Bill Pringlemeir

Asus K7V here, 800 MHz Athlon oc to 880 MHz, 256 Mb, occasional XFree86 lockups, otherwise stable with almost any of the v2.4.x series including -ac variants and the testing kernels. Right now 2.4.6-pre5, doing fine.

Running 2.4.6-pre and 2.4.6 proper on several machines. Quite busy and all have 256 to 512MB of RAM. As I type this, I am in the process of converting an entire production server farm over to 2.4.6 from 2.2.19 as the 2.4.6-pre series proved out well on a test machine in that farm. No stability problems at all. The only reboots were for patching up the kernel to the next -pre revision on that test box.

I suggest you look into the memory settings in your BIOS, and change them to the most conservative available. Or, throw out your memory and buy some from a reputable manufacturer. Your problem is definitely hardware. There are racks full of linux machines with more than 128 MB RAM running kernel 2.4 all over the world. I personally installed a dozen. It always works fine.

-jwb

Some motherboards have ram requirements that might not be obvious without reading the m/b manual. For example, some m/b's require registered memory. Some don't work with ECC. Some require modules be installed in pairs (of exact type match). Some require that larger memory sticks be placed in earlier slots relative to smaller modules. And if you add a wait state in the bios a marginal ram module can become quite stable; the unstable version can behave differently under different circumstances (including temperature). Check the m/b manual and m/b web site for exact requirements, and make sure the ram matches; even if your memory is good, it might not be good in your circumstances.

D. Stimits, [email protected]

Yes, I have an Athlon 700 on a Asus/K7V motherboard with 256 MB PC 133 RAM. Never had any problem with this configuration. Before that, however, there was an Pentium 120 with 64 MB RAM. This one used to crash during kernel-compiles due to an overheated processor. Really funny. Later I got kernel-panics during boot due to pagetable-corruption. This time it was bad RAM and went awayx after I changed one certain module. So I would almost certainly relate Your problem to hardware failure.

Good success

Peter B

Nobody has answered a basic concern:
Why does Win2k work while Linux does not?

We already know that MiciSoft sometimes helps make stupid standards like P&P ISA cards and then writes drivers for them. Something that is hard to do for any _sane_ developers who did not help make the stupid "standard".

Having said that, if anybody has a technical answer for Ronald please give it to him. He says:
My systems ARE FINE BECAUSE Win2k runs on them. This deserves a direct technical answer if anybody has one.

--------------------
I'm a Linux user and proud of it.

The answer could be as simple as the fact that Linux might be trying to write to the exact memory location that is bad but Win2k has not. It might also be that he in fact DOES have problems with win2k but is unaware of it, that location might be used for data storage rather than program execution.

All I can say is this ... I have never used Windows on our production web farms and Linux 2.4 appears to work just fine will many different sizes of memory ... all greater than 128MB.

I did post a possible answer for this: different OSes excercise the memory subsystem very differently. This is why a box might run (say) Win95 apparently stably, but not be able to run Linux. The same reasoning applies to other OSes. I've seen this many times myself.

Charles

-----------------------------------------------------------------------
Charles Cazabon                            <[email protected]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------

%uname -a
Linux cartman 2.4.0-64GB-SMP #1 SMP Wed Jan 24 15:52:30 GMT 2001 i686 unknown
%uptime
8:35am up 57 days, 12:42, 2 users, load average: 2.00, 2.00, 2.00
%free
total used free shared buffers cached
Mem: 254904 251968 2936 0 92224 45028
-/+ buffers/cache: 114716 140188
Swap: 524656 14192 510464

Could this be a 2.4 swap issue. You NEED at least RAM x2 swap. If you're just adding memory to
a box that's stable with 128 megs and possibly 256 megs swap (you don't state, just guessing..)
you've now got too little swap, and boom, stability goes bye-bye.

Just haven't seen the swap issue mentioned this thread...

=Don=

Hmm,

I have no problems either.

Asus KT7 KT133 Chipset

root@station2-lnx:~# uname -a
Linux station2-lnx 2.4.6 #10 Thu Jul 5 11:08:39 CDT 2001 i686 unknown
root@station2-lnx:~# free
             total       used       free     shared    buffers     cached
Mem:        512944     509888       3056          0      32140     417532
-/+ buffers/cache:      60216     452728
Swap:      1100444          0    1100444

Gary White               Network Administrator
[email protected]          Internet Pathway
Voice 601-776-3355            Fax 601-776-2314

Hi back at you :-)

This can mean (but is not limited to) that the second memory module is bad, or can't keep up with the DRAM controller. An obvious test is to replace your existing memory module with the other memory module and see if you experience problems. If you experience no problems, then it's not the module. Most likely it's the DRAM controller (or a capacitence problem due to timing). Some BIOSs allow you to adjust the DRAM controller timings (RAS, CAS, clock). You may have to slow down the timings to stabalize the memory access.

I have a DELL computer at work that is supposed to be able to take 128M (4 banks of 32M) in SIMMs, but no matter what brand of memory (I went through 4 different manufacturers), it always caused OS crashes. Yet, if I load it with 64M (4 banks of 16M) its completely stable. That computers BIOS doesn't allow me to change the DRAM timings, so I'm stuck with 64M. This is just to illustrate that it might not be the memory, but the controller thats the problem.

When you boot the installer (either from CD or floppy) you get the option to add kernel parameters before the installer kernel actually boots. Try adding the parameter "mem=128M" or "mem=64M". This will restrict the installer to using a subset of the total memory. In my experience, the installer environment of most distributions is not very robust, but once installed, the normal system is quite stable.

Really, we need more information than "can't linux-2.4.x run on ANY machine". What brand/make motherboard?

Each OS allocates the physical memory differently. MS-Windows typically allocates physical memory sequentually. Linux tends to uses both ends of the memory pool. For a proper test, you need to load enough programs so that all of physical memory will be utilized. Win2k may be "stable" because you aren't loading enough of the system to touch the second bank of memory. Please try running several large programs and exercise them all together for several minutes. You can use the task manager to find the total memory used on the system.

It's kinda funny, but I actually use MS-Windows NT as a memory/controller tester ;-). In my experience, I've found that Windows is much more demanding/picky of the hardware than Linux is (Linux installer experiences being the notable exception).

Peter A. Castro <[email protected]> or <[email protected]>
	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Hi all,

Pheew (this is sarcastic)
You're fully correct, after toying a bit on win2k, I crashed it a few times with weird errors and I must say, these blue screens in win2k look a *lot* better than the ones I used to see in win98 ;-). They still don't match that wonderful "kernel panic", though.

So, basically, my bios must have loaded the wrong options for my memory which must run above it's limits which causes data corruption... Then, my stupid question, why doesn't memtest86 detect that?

Anyway, I'll go look at the bios settings of the computers, look at the CAS/RAS/clock timing settings like two people suggested (thanks :-) ) and hope to be happy and have a stable machine after that.

Thanks for this half-solution :-)

--
Ronald Bultje

Because it's a memory tester and not real work load. It tries special access patterns to find hard memory errors (i.e. memory cells that are damaged). Timing and configuration errors are harder to find. For one thing, these might depend on temperature, and memtest86 won't stress the CPU into generating as much heat as real work will do.

According to your posts, you are using no-name SDRAMs, and two different ones. I have already posted that, their configuration data is often incomplete or just erronous and the BIOS will be confused or has just errors itself (like configuring all SDRAMs to the values of the first one).

The German computer magazine c't has some time ago bought no-name and branded SDRAMs and tested them extensively (checked config ROM data, put them in a lended $500000 memory tester). Results were that no-names were on average pretty crappy. The branded ones weren't perfect, but much better. A month after that article pretty much every computer store here had brand SDRAMs in addition to the cheap no-name stuff.

If you can get hold of the timing values for your RAM (might be hard with no-name, use conservative values otherwise) then it's better to set these directly instead of letting the BIOS go around playing with that stuff.

autodetection, left it out of the BIOS and require the user to configure it themselves if they want some performance.

Andreas E. Bombe <[email protected]>    DSA key 0x04880A44