All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Jacob Martin <martin@cs.uga.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PROBLEM:  OOPSes in PREEMPT SMP for AMD Opteron Dual-Core with Memhole Mapping (non tainted kernel)
Date: 13 Jun 2005 12:06:04 +0200
Date: Mon, 13 Jun 2005 12:06:04 +0200	[thread overview]
Message-ID: <20050613100604.GA18976@muc.de> (raw)
In-Reply-To: <200506121529.50259.martin@cs.uga.edu>

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

On Sun, Jun 12, 2005 at 03:29:50PM -0400, Jacob Martin wrote:
> Hardware memhole mapping never seems to work, or causes lockups right away.  I 
> need to test it further though.
> 
> I have discovered that with the following features enabled:
> 
> 1.  Software memhole mapping
> 2.  Continuous,
> 
> linux sees the entire 4GB of memory.  However, when things start getting 
> requested from the upper half, there are Oopses generated.  Attached are two 
> Oopses that occurred under the test scenario described.  

What happens when you boot with numa=off or with numa=noacpi ? 

The system seems to believe it has memory in an area not covered
by mem_map.


> launch big memory apps.
> 
> I suppose I could write a program to consume/probe the upper memory half.  
> Anyone know of a good/quicky way to do that?  

You can use the attached program which I often use for similar purposes.
It writes nearly all free memory in a loop and also often triggers memory 
problems.

-Andi


[-- Attachment #2: memeat.c --]
[-- Type: text/plain, Size: 912 bytes --]

#define _GNU_SOURCE 1
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(void)
{
	size_t linelen = 0;
	char *line = NULL;
	unsigned long freemem = 0;
	FILE *f = fopen("/proc/meminfo", "r");
	while (getdelim(&line, &linelen, '\n', f) > 0) { 
		if (sscanf(line, "LowFree: %lu", &freemem) == 1)
			break; 
	} 

	freemem *= 1024; 

	freemem -= freemem/20;
	char *s = malloc(freemem);
	if (s) {
		long i;
		for (;;) { 
		printf("\nwrite\n");
		for (i = 0; i < freemem; i += 10*1024*1024) {
			long w = freemem - i;
			if (w > 10*1024*1024)
				w = 10*1024*1024;
			memset(s + i, 0xff, w);
			putchar('.');
			fflush(stdout);
		}
		printf("\nread\n");
		for (i = 0; i < freemem; i += 10*1024*1024) {
			long w = freemem - i;
			if (w > 10*1024*1024)
				w = 10*1024*1024;
			memcpy(s, s + i, w);
			putchar('.');
			fflush(stdout);
		}
		}
	} else
		printf("Cannot allocate memory\n");
	
	return 0;
}

  reply	other threads:[~2005-06-13 10:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-07 22:36 PROBLEM: OOPSes in PREEMPT SMP for AMD Opteron Dual-Core with Memhole Mapping (non tainted kernel) Jacob Martin
2005-06-11 10:41 ` Andi Kleen
2005-06-11 14:31   ` Jacob Martin
2005-06-12 19:29   ` Jacob Martin
2005-06-13 10:06     ` Andi Kleen [this message]
2005-06-13 19:53       ` Jacob Martin
2005-06-15 19:51         ` Andi Kleen
2005-06-15 20:46           ` Jacob Martin
2005-06-15 22:33           ` Jacob Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050613100604.GA18976@muc.de \
    --to=ak@muc.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin@cs.uga.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.