I recently upgraded my machine to 1GB so I had to switch on the
CONFIG_HIGHMEM setting. Ever since although the kernel has been OK
userspace apps have started dropping out for no apparent reason
(gkrellm, for example, crashes about every 10 minutes).
What does CONFIG_HIGHMEM actually modify that could affect userspace? I
was under the impression it just moved the kernel structures higher up
in the memory space.
Unfortunately memtest86 is incompatible with this mobo, but the memory
checks out on another machine I tried it on, so I expect it's OK.
Tony
--
"Wipe Info uses hexadecimal values to wipe files. This provides more
security than wiping with decimal values." -- Norton SystemWorks 2002 Manual
[email protected]
http://www.nothing-on.tv
> Unfortunately memtest86 is incompatible with this mobo, but the memory
> checks out on another machine I tried it on, so I expect it's OK.
memtest86 is incompatible in what way ?
Alan Cox wrote:
>>Unfortunately memtest86 is incompatible with this mobo, but the memory
>>checks out on another machine I tried it on, so I expect it's OK.
>>
>
> memtest86 is incompatible in what way ?
>
It won't boot - it just hangs on a red screen with 'Memtest86' written
on the corner.
Tony
On Sunday, January 6, 2002, at 11:57 , Tony Hoyle wrote:
>
> Unfortunately memtest86 is incompatible with this mobo, but the
> memory checks out on another machine I tried it on, so I expect
> it's OK.
I've had DIMMs not get along. So have other people. This little
tester seems to find that fairly well, stunningly --- even when
Memtest86 can't find them at all. It found mine in about 30min
(512mb box); another persons in an hour or two.
Adjust the defines up top.
PS: You did report the failure to the memtest86 people, right?
#include <iostream>
#include <cstdlib>
#include <ctime>
#ifdef TWO_PROCESSOR
# include <unistd.h>
# include <cstdio>
#endif
#define BLOCK_TYPE int
#define BLOCK_SIZE (32*1024*1024/sizeof(BLOCK_TYPE)) /* = 32MB */
#define BLOCK_COUNT (15) /* = 480MB */
using namespace std;
void FillBlock(BLOCK_TYPE *ptr);
void CheckBlock(BLOCK_TYPE *ptr, int seed, int ident, int proc);
int main() {
BLOCK_TYPE *block[BLOCK_COUNT];
int seed[BLOCK_COUNT];
cerr << "Allocating Blocks...\n";
for (int x = 0; x < BLOCK_COUNT; ++x)
block[x] = new BLOCK_TYPE[BLOCK_SIZE];
cerr << "Done allocating blocks.\n";
cerr << "Filling blocks...\n";
for (int x = 0; x < BLOCK_COUNT; ++x) {
int rnd = rand();
srand(rnd);
seed[x] = rnd;
FillBlock(block[x]);
};
cerr << "Done filling blocks.\n";
#ifdef TWO_PROCESSOR
int proc_ident;
{
int res = fork();
if (res == 0) {
srand(time(NULL));
proc_ident = 1;
} else if (res == -1) {
perror("fork");
exit(1);
} else
proc_ident = 0;
}
#else
int proc_ident = 0;
#endif
cerr << "Running test. This will take forever.\n";
while (1) {
int which = (rand() % BLOCK_COUNT);
CheckBlock(block[which], seed[which], which, proc_ident);
}
return 0;
}
void FillBlock(BLOCK_TYPE *ptr) {
for (BLOCK_TYPE *stop = ptr+BLOCK_SIZE-1; ptr < stop; ++ptr)
*ptr = rand();
}
void CheckBlock(BLOCK_TYPE *ptr, int seed, int ident, int proc) {
int old = rand();
srand(seed);
for (BLOCK_TYPE *stop = ptr+BLOCK_SIZE-1; ptr < stop; ++ptr) {
BLOCK_TYPE got = *ptr;
BLOCK_TYPE want = rand();
if (got != want)
cerr << "Block #" << ident << " (" << proc << ") not OK; *"
<< ptr << " = " << got << ", not " << want << "!\n";
}
srand(old);
}
Anthony DeRobertis wrote:
>> Unfortunately memtest86 is incompatible with this mobo, but the memory
>> checks out on another machine I tried it on, so I expect it's OK.
>
I've had no other instablility problems, and downgrading gkrellm to the
previous version seems to have stopped it dying. Mozilla started being
very unstable at the same time.. it could just be a coincidence that
they all happened at the same time.
> I've had DIMMs not get along. So have other people. This little tester
> seems to find that fairly well, stunningly --- even when Memtest86 can't
> find them at all. It found mine in about 30min (512mb box); another
> persons in an hour or two.
I'll run it & see if anything fails.
> PS: You did report the failure to the memtest86 people, right?
Their website says not to report bugs unless you're prepared to do a
fair bit of debugging yourself. It also says individual problems won't
normally be dealt with... I took the hint and didn't bother.
Tony
On Tuesday, January 8, 2002, at 12:45 PM, Stephan von Krawczynski wrote:
Mozilla's since around 0.9.2 have been stable for me. Some leak
resources faster than others, but that seems to be improving
generally.
Odd that your mozilla isn't quite so stable. I have mine running
for days on end without issues, other than leaks.