Follow-up Comment #1, bug #7118 (project hurd):
Here is additionnal information from http://bugs.debian.org/226609:
Message received at [EMAIL PROTECTED] (full text, mbox):
From: Michael Banck <[EMAIL PROTECTED]>
To: Robert Millan <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Processed: Re: Bug#226609: crosshurd: Problem with much memory
Date: Mon, 1 Mar 2004 15:49:53 +0100
On Wed, Jan 07, 2004 at 02:48:20PM -0600, Debian Bug Tracking System wrote:
> Processing commands for [EMAIL PROTECTED]:
>
> > reassign 226609 gnumach
> Bug#226609: crosshurd: Problem with much memory
> Bug reassigned from package `crosshurd' to `gnumach'.
>
> > thanks
> Stopping processing here.
Robert, if you reassign a bug, please also CC the maintainer (bug-hurd
in this case), or else he will have no context what this bug is about.
This is from the original report:
|with my ASUS P4G8X P4 machine with an Intel E7205 chipset and 1GB of
|RAM, the kernel reboots on booting. The debian-hurd list archives
|include a message from November 2003 that using GRUB "uppermem 786432"
|solves the problem. It didn't for me. Removing half of my memory worked.
|
|Others with 768 MB RAM don't have the problem.
|
|Using GRUB "uppermem 524288" also works for me (with 1GB physically
|installed).
|
|I'm not sure if this is an upstream bug. Maybe it is just solved there.
|We can reassign it upstream if the next gnumach/hurd update for Debian
|doesn't fix the problem.
I read through some old irc logs yesterday on the occasion of the
rebirth of hurd-devel, and found this conversation between Neal and
Thomas, which seems to be relevant:
<Varg> manuel: well I have 1Gig, if that could be the problem
<neal> Well, that could be the problem.
<neal> Try getting that under 768.
<Varg> Ugnh --- any chance of doing that without ripping the DIMMs out?
<Varg> i.e with some boot option or something?
<thomb> is there really a bug like that neal? geez, it should be pretty
easy to make Mach just ignore extra memory; that's better than
breaking!
<neal> Nope.
<neal> One would think.
<thomb> if that's a real restriction, it should be listed on the BTS
<manuel> hmm yeah, I think it is listed on the limits page on the wiki
<thomb> but it is also a bug that could be easily fixed in Mach (at
least to ignore the extra memory, if not to use it)
<Varg> hmm, well I think I'm gonna follow the changelogs and get it once
the problem is resolved :-)
<neal> The most I was able to boot with was 640.
<thomb> neal: when you had lots of ram, did you have this kind of weird
symptom?
<manuel> neal: 768 here
<Phython> use the uppermem command to tell gnumach you have less memory
<neal> That was also the most I had.
<Phython> uppermem 654720
<Phython> will limit your memory to 640Mb
<neal> Mach respects that?
<Phython> neal: I don't know, it should though
<Varg> ok, trying. brb
-!- Varg [EMAIL PROTECTED] has quit ["[x]chat"]
<neal> Hmm, I think I have found a work around.
<neal> Something along the lines of:
<neal> @@ -652,8 +652,10 @@ void pmap_bootstrap()
<neal> * mapped into the kernel address space,
<neal> * and extends to a stupid arbitrary limit beyond that.
<neal> */
<neal> - kernel_virtual_start = phys_mem_max;
<neal> - kernel_virtual_end = phys_mem_max + morevm;
<neal> + if (phys_last_addr - phys_first_addr > 768 * 1024 * 1024)
<neal> + phys_last_addr = phys_first_addr = 768 * 1024 * 1024;
<neal> + kernel_virtual_start = phys_last_addr;
<neal> + kernel_virtual_end = phys_last_addr + morevm;
<neal> thomb : Do you think that is reasonable?
-!- Varg [EMAIL PROTECTED] has joined #hurd
<Varg> it wooo-hooorks :-)))
<neal> Well, I guess no work around is needed.
<neal> Or, at least not that one.
<neal> Varg : What did you do exactly?
<Varg> neal: I applied the grub uppermem command, limiting my memory to
640MB
<neal> Excellent.
<Phython> neal: will that be added to the FAQ?
<neal> I was in the process of doing it.
<thomb> varg: that's good; then it means that a quickie patch to Mach
should be easy as well, because it isn't a real hardware problem
in booting andhaving lots of memory.
<neal> thomb : Mach maps all of the physical memory at the bottom of the
kernel address space.
<neal> thomb : Thus when it goes to map virtual memory, it has no space
for mappings.
<neal> thomb : At least that is my reading of the code.
<thomb> right, i see the problem. So it will be a pain to fix for real,
but should be easy to add a line to just clamp physical memory
at some reasonable value.
At least the part of the code Neal hinted at does not seem to have
changed, can anybody say whether this issue has been fixed in CVS (and
thus, the latest Debian package)?
If not, does Neal's approach still seem reasonable? Did anybody ever
test this? I guess > 768 MB of RAM are getting increasingly common, so
having a work-around for the immediate crash would be nice.
thanks,
Michael
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=7118>
_______________________________________________
Message posté via/par Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
