CONFIG_HIMEM instability?

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

memtest86 is incompatible in what way ?

It won't boot - it just hangs on a red screen with 'Memtest86' written on the corner.

Tony

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);
}

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'll run it & see if anything fails.

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