* Flexible mem= parameter
@ 2006-04-13 22:49 Jan Engelhardt
2006-04-13 23:21 ` Randy.Dunlap
2006-04-18 8:49 ` Denis Vlasenko
0 siblings, 2 replies; 3+ messages in thread
From: Jan Engelhardt @ 2006-04-13 22:49 UTC (permalink / raw)
To: Linux Kernel Mailing List
Hello,
mem= can be used to limit the amount of physical memory Linux uses. I
presume that when specifying mem=256M only the memory from 0x0 to
0x10000000 is used. Is there a way to tune mem= so that it will use
0x70000000 to 0x80000000? (A compile-time change would suffice.)
Background: I am trying to track down a nondeterministic (but
reproducible) segfault while building big projects like gcc or glibc. I do
not think it's a memory problem since it only showed up since I changed to
gcc 4.1.0 and tweaked it to use -mcpu=ultrasparc (rather than -mcpu=v7) by
default. I had been building gcc4 before with gcc3 a number of times w/o
problems. I did ran a userspace memtester for approx 20 hours (`memtest`
from debian).
Jan Engelhardt
--
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Flexible mem= parameter
2006-04-13 22:49 Flexible mem= parameter Jan Engelhardt
@ 2006-04-13 23:21 ` Randy.Dunlap
2006-04-18 8:49 ` Denis Vlasenko
1 sibling, 0 replies; 3+ messages in thread
From: Randy.Dunlap @ 2006-04-13 23:21 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linux-kernel
On Fri, 14 Apr 2006 00:49:12 +0200 (MEST) Jan Engelhardt wrote:
> Hello,
>
> mem= can be used to limit the amount of physical memory Linux uses. I
> presume that when specifying mem=256M only the memory from 0x0 to
> 0x10000000 is used. Is there a way to tune mem= so that it will use
> 0x70000000 to 0x80000000? (A compile-time change would suffice.)
>
>
> Background: I am trying to track down a nondeterministic (but
> reproducible) segfault while building big projects like gcc or glibc. I do
> not think it's a memory problem since it only showed up since I changed to
> gcc 4.1.0 and tweaked it to use -mcpu=ultrasparc (rather than -mcpu=v7) by
> default. I had been building gcc4 before with gcc3 a number of times w/o
> problems. I did ran a userspace memtester for approx 20 hours (`memtest`
> from debian).
I've never tried it, but Documentation/kernel-parameters.txt
suggests using mem= along with memmap= to specify an exact memmap.
memmap=nn[KMG]@ss[KMG]
[KNL] Force usage of a specific region of memory
Region of memory to be used, from ss to ss+nn.
Is this on a sparc system or are you just building sparc tools?
I don't know if memmap= works on sparc arch.
---
~Randy
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Flexible mem= parameter
2006-04-13 22:49 Flexible mem= parameter Jan Engelhardt
2006-04-13 23:21 ` Randy.Dunlap
@ 2006-04-18 8:49 ` Denis Vlasenko
1 sibling, 0 replies; 3+ messages in thread
From: Denis Vlasenko @ 2006-04-18 8:49 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linux Kernel Mailing List
On Friday 14 April 2006 01:49, Jan Engelhardt wrote:
> Hello,
>
>
> mem= can be used to limit the amount of physical memory Linux uses. I
> presume that when specifying mem=256M only the memory from 0x0 to
> 0x10000000 is used. Is there a way to tune mem= so that it will use
> 0x70000000 to 0x80000000? (A compile-time change would suffice.)
On i386 this works:
"mem=exactmap mem=640K@0 mem=79M@1M"
> Background: I am trying to track down a nondeterministic (but
> reproducible) segfault while building big projects like gcc or glibc. I do
> not think it's a memory problem since it only showed up since I changed to
> gcc 4.1.0 and tweaked it to use -mcpu=ultrasparc (rather than -mcpu=v7) by
> default. I had been building gcc4 before with gcc3 a number of times w/o
> problems. I did ran a userspace memtester for approx 20 hours (`memtest`
> from debian).
--
vda
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-04-18 8:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-04-13 22:49 Flexible mem= parameter Jan Engelhardt
2006-04-13 23:21 ` Randy.Dunlap
2006-04-18 8:49 ` Denis Vlasenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®