CONFIG_HIMEM instability?

CONFIG_HIMEM instability?

[Tony Hoyle]

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

tmh@nothing-on.tv 
http://www.nothing-on.tv

Re: CONFIG_HIMEM instability?

[Tony Hoyle]

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

Re: CONFIG_HIMEM instability?

[Alan Cox]

> 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 ?

Re: CONFIG_HIMEM instability?

[Anthony DeRobertis]

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

Re: CONFIG_HIMEM instability?

[Tony Hoyle]

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

Re: CONFIG_HIMEM instability?

[Anthony DeRobertis]

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.