Hey everyone,

I'm running slack 10 with the 2.4.26 kernel.

A while back I got america's army running for linux. The game runs
just as well as it does under windows, but unfortunately segfaults
every so often.

I have a 512 stick of off brand abyte in my pc. My suspicion is that
the ram contains a tiny flaw which only shows itself during intensive
operations. Does anyone know of a ram checker for linux?

Also, given slacks rep for stability, I thought perhaps I should
consult you guys about possible ways to improve my stability under
linux. I should note that in every other case I can think of this
slack install has been rock solid.

I've heard perhaps such options as acpi, hotplug, etc may lead to
instability in certian situations. Does anyone have any suggestions
as to how i might increase stability under high load conditions in
slack?

sibersmith wrote:

> Hey everyone,
>
> I'm running slack 10 with the 2.4.26 kernel.
>
> A while back I got america's army running for linux. The game runs
> just as well as it does under windows, but unfortunately segfaults
> every so often.
>
> I have a 512 stick of off brand abyte in my pc. My suspicion is that
> the ram contains a tiny flaw which only shows itself during intensive
> operations. Does anyone know of a ram checker for linux?
>
> Also, given slacks rep for stability, I thought perhaps I should
> consult you guys about possible ways to improve my stability under
> linux. I should note that in every other case I can think of this
> slack install has been rock solid.
>
> I've heard perhaps such options as acpi, hotplug, etc may lead to
> instability in certian situations. Does anyone have any suggestions
> as to how i might increase stability under high load conditions in
> slack?

http://linux.maruhn.com/sec/memtest86.html
it's a boot image. if you run lilo, you can configure it to come up in the
list at boot time, and then you boot into the image, and it'll run fast or
extensive ram tests

however, you can always get something for dos, and run it off of a dos boot
disk
--
lucas
-------------------------
Perl Coder since 2001
shift || die;
-------------------------

lucas wrote:
> http://linux.maruhn.com/sec/memtest86.html
> it's a boot image. if you run lilo, you can configure it to come up in
> the list at boot time, and then you boot into the image, and it'll run
> fast or extensive ram tests

memtest is far from comprehensive - I have a stick of SpekTek 512 DDR going
back because it seg faults after about 5 minutes.

Running memtest overnight revealed absolutely no errors.

Sticking the same stick into an XP box brings on a crash shortly after
booting.

Watching memtest run I assume it isn't checking for page crossover errors -
writing to the edge of a page generates a write to a physically associated
page - the standard readback check wouldn't find such an error but it would
play hell with Linux's caches and buffers.

The best test is to try a different stick of similar type memory, erhaps by
a different manufacturer.

Best,

Brian

On Mon, 20 Sep 2004 17:53:18 +0000, lucas wrote:

> http://linux.maruhn.com/sec/memtest86.html
> it's a boot image. if you run lilo, you can configure it to come up in the
> list at boot time, and then you boot into the image, and it'll run fast or
> extensive ram tests

memtest86 is getting very long of tooth. I've gotten satisfactory results
on newer hardware with memtest86+ (http://www.memtest.org/), which is a
maintained version of memtest86. YAMMV.

OB

Brian wrote:

> lucas wrote:
>> http://linux.maruhn.com/sec/memtest86.html
>> it's a boot image. if you run lilo, you can configure it to come up in
>> the list at boot time, and then you boot into the image, and it'll run
>> fast or extensive ram tests
>
> memtest is far from comprehensive - I have a stick of SpekTek 512 DDR
> going back because it seg faults after about 5 minutes.
>
> Running memtest overnight revealed absolutely no errors.
>
> Sticking the same stick into an XP box brings on a crash shortly after
> booting.
>
> Watching memtest run I assume it isn't checking for page crossover errors
> - writing to the edge of a page generates a write to a physically
> associated page - the standard readback check wouldn't find such an error
> but it would play hell with Linux's caches and buffers.
>
> The best test is to try a different stick of similar type memory, erhaps
> by a different manufacturer.

Thanks for the tip. Does all mem test software do the same tests? I have a
few different programs for testing memory, and I find it hard to beleive
that they all could miss the same thing.

regards,
--
lucas
-------------------------
Perl Coder since 2001
shift || die;
-------------------------

sibersmith@yahoo.com (sibersmith) wrote:
>A while back I got america's army running for linux. The game runs
>just as well as it does under windows, but unfortunately segfaults
>every so often.
>
>I have a 512 stick of off brand abyte in my pc. My suspicion is that
>the ram contains a tiny flaw which only shows itself during intensive
>operations. Does anyone know of a ram checker for linux?

What kind of a segfault are you getting?

I would think that setting ulimits on the size of a core file to
something which allows a core dump (do "help ulimit" from a bash
command line) could potentially be useful (though perhaps not at
all). You would at a minimum be able to determine if it was always
happening at the same point in the program, which would clearly
implicated the program.

The simple fact is that unless you are always using *exactly*
the same set of processes, and never do anything different, it
is very unlikely that only one program would be having problems
if you had a faulty stick of RAM. Much more likely would be
some very random results, _or_ it would bomb during some part of
the initial setup process (booting, logging in, running X). But
once you get past that point, the exact part of RAM that any
given program is assigned is pretty much random, depending on
what else was running just before it. As a result, you'd be
getting segfaults on whatever process just happened to use the
bad RAM.

On the other hand, a large program might appear to "randomly"
segfault, as it does background tasks which are not apparent to
the user, and hence the actual cause of a segfault is not
directly tied to any specific user action. For example,
Netscape and Opera are the two web browsers that I use, and they
both bomb out on an irregular basis. Annoying, but there isn't
much I can do about it.

--
FloydL. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

lucas wrote:
> Brian wrote:
>> The best test is to try a different stick of similar type memory, erhaps
>> by a different manufacturer.

> Thanks for the tip. Does all mem test software do the same tests? I have
> a few different programs for testing memory, and I find it hard to beleive
> that they all could miss the same thing.

Can't speak for them all Lucas - just swapping out a stick of DDR is much
faster than waiting overnight for some memory test to complete.

Best,

Brian

Floyd L. Davidson wrote:

<clipped for brevity>

Floyd is 100% right - you are likely experiencing a problem with your game
app.

I on the other hand always experienced problem after a set amount of
activity - memtest revealed nothing but replacing the stick cured the
problem.

Different circumstances.

Best regards,

Brian