Greetings,

Thanks to all of you who responded to my message last week.

> "Kenneth Pritchard  wrote"

> What does top report for total memory and what does it report for the

mem

> usage of the processes you are concerned with.

        It reports 128 MB of RAM, and the victimized processes use less

than 10%.

> Mike Still wrote:

> I believe that is a fairly common problem.  Either try some more

recent

> kernels  and see if the problems go away or keep decreasing the amount

of ram in

> lilo.conf by 1M to see if that works (mem=127M).  i remember a certain

problem where

>the bios only exhibits this kind of problem at 128M.

        1. Not that easy to switch kernels, but willing to try (but see

below) .

        2. I have to go to 64MB  (Redhat OS) for the problems to go

away, 48MB for Debian. This with

            a line in lilo.conf (for SIMMS swapping see below).

> Ray Knight wrote:

> What chipset does your motherboard have?  Many of the Intel chipsets

are not

> capable of caching more than 64M of memory and this may be related to

the

> problem.

            Intel 1430 VX. The documentation on the motherboard tells me

that I can go to 128MB.

> Dr Robert Stickel wrote:

> Sounds like you may have a flaky simm.  Here are a couple of memory

> testers you might want to try:

> http://reality.sgi.com/cbrady_denver/memtest86/

> This one goes on a boot floppy and runs all by itself.

> http://www.qcc.sk.ca/~charlesc/software/

> This one runs under an OS.

>I've tried memtest86 but not the other one (yet).

          I downloaded and then used the "memtest86" and let it run for

the better part of an hour,         with all kinds of tests. Not a

single error reported.

>  Glenn C. Lasher wrote:

>  I  have two thoughts:

>  1.  defective memory?

>  2.  Did you enlarge your swap space accordingly?

>  I'm kind of grasping at straws here, but there are my thoughts.

        I had already enlarged the swap space to exceed the RAM. No

good.

        Defective memory:  see test results.

------------------------------------------------------------------

Having tried many of the suggestions above and a few of my own without

succes, I got desperate and started swapping SIMMS. First went back to

my old configuration (48 MB) and old SIMMS. No problems. Then upgraded

on by one (or I should say two by two since this works with pairs) from

48MB to 80 MB to 96MB. No problems! The problems start with 128MB. Flaky

SIMM anyway? I looked up some documentation and I found that it is

recommended to have all of the chips on the SIMMs from the same

manufacturer. Well, on at least one of the 32MB  SIMM it was a mishmash

.

It appears that each of the SIMMS was flawless, but they refuse to work

together. Slight timing differences possibly; when the specs say 60

nanoseconds, it could well be 65 for example. Small differences in pulse

shape maybe.

Anyway, for the time being I have to live with 96 Mb instead of 128MB

and try to get Micro Center to take back the other two 32MB SIMM.

Thanks again to all of you. Cor van Dijk

---------------------------------------------------------------------

Original message:

>

> Greetings,

>

> I upgraded my  triple boot (Redhat6.0/Debian2.1/Windows95) Pentium

from

> 48MB to 128MB. Each OS on its own drive. Redhat immediately found the

> 128MB, so did Windows. For Debian I inserted

>     append="mem=128M"

> in its lilo.conf stanza; then Debian also found the 128MB. All systems

> boot fine and report the proper RAM size.

> My problems start when I run things like "cdrecord" which appears to

> lock certain areas of memory (with mlockall?) or "cdparanoia"  or

> "cdrdao".  After a few minutes running, these programs cause

> segmentation faults and complain about their buffers only partially

> filled. Both Debian and Redhat have this problem. With 48 MB RAM this

> never happened.

>

> If I force a limit of 64MB (with a line in lilo.conf)  then the

problem

> goes away.  I can find nothing in the FAQ's or HOWTO's about problems

> like this. Can somebody please put me on a track to resolving this

> problem? Thanks a lot in advance!

>

> Cor van Dijk.

>


--
To unsubscribe: mail ">majordomo@ale.org with "unsubscribe ale" in message body.