Hi,
Only when i was trying to compile the gcc package following the LFS book instruccions did i realize that i might had a memory problem, due to the constant sig 11 error in always different functions.

Now, i was trying to follow the LFS advice to use memtest86(www.memtest86.com) to find the defective part of the ram and then tell the kernel not to make use of that using the badram kernel patch.
The problem is that i don't know how to work with memtest86 and the manual(if you can call it that) isn't very helpful.

I mean, under the errors counts, i have 158 in only one pass. Isn't that too much? And how do i get the information needed to put badram to work? Is there a better memtest86 manual?

Thanks.

that's going to be way more trouble than it's worth. you're going to spend days work on maybe fixing what could be fixed with $15 worth of ram.

Well, maybe that's true, but if the ram is not yet(completly) useless and if i will only lose like 2 or 3 Mb and it will not affect the speed(as proven by the benchmarks on badram homepage), then i think it is worth the trouble. Even because, there is always the chance it will happen again and i rather spend the time learning and, why not, saving some money.

That's one of the main things i like about linux...my amd k6-2 333mhz, 32mb still serves me as my desktop pc.

Those are my reasons...any help?

i have the same troubles and i can get it working. but i'm also confused about these patterns (specialy bitmask).

mritch

i would try the badram thing too, i think. it's too cool not to try. in the old days there was a ram refresh utility. i'm talking about back in the days of 1-4 megs of ram on a high end desktop. it would refresh your ram at whatever interval you wished, which sometimes could solve bad ram problems. back then ram was $40 a meg. i would have learned how to use badram myself, but all my machines are multi-boot, and when i have trouble with ram in one machine, it will often work in some other computer.

http://badmem.sourceforge.net/docu/BadMEM-HOWTO.html

the solution:

the pattern consists of a address A and bitmask M. badram=A,M,A,M,..
you can find the (faulty) address A with eg memest86.

0x01000000 equal 16mb

here are masks M some may use:

0xff000000 +16mb
0xff800000 + 8mb
0xffc00000 + 4mb
0xfff00000 + 1mb
0xfffffffc +4k

so a bootparameter like "badram=0x01000000,0xff800000"
will reserve 8mb of the installed ram starting at 16mb till 24mb.

Hi,

Fortunately, i already solved the problem. It was a hardware problem, but it was the processor that was heating too much because of the dirt(which i of course have already cleaned).
Now, i have another question. I still have the memory module with errors and i've tested the compilation of the kernel and it gave no errors, which would indicate a stable system.
But now i don't know if i should trust it, because memtest86 gives several bad bits, but the system runs smoothly.

Should i still go through the trouble of badram? Is it safe to compile under this circunstances? If it doesn't gives an error it's ok, right?

that depends on your needs. since my sys is a server for several people and i can't watch it all day long i decided to use badram to take a secure place around the bad spots out. it ran the last week without any problems. i'll test for the next few month. sometimes it will be necessary to test if there are new errors in memory.
keep in mind, that a faulty memory even can harm your filesystem - and if it's something important it kills, it wouldn't only be hard to find - also it may kill the funktionality of your sys.
since there seem to be no performance issue and if you can waste a few kb i'll suggest to use it.
if it's a workstation and no errors are reported after compiling a few kernels it might also be a false-alarm and you may not need to use the patch.