[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #7118] GNU Mach can't handle 1G memory

From: Samuel Thibault
Subject: [bug #7118] GNU Mach can't handle 1G memory
Date: Mon, 26 Dec 2005 22:08:11 +0100
User-agent: w3m/0.5.1

Follow-up Comment #1, bug #7118 (project hurd):

Here is additionnal information from http://bugs.debian.org/226609:

Message received at 226609@bugs.debian.org (full text, mbox):

From: Michael Banck <mbanck@debian.org>
To: Robert Millan <zeratul2@wanadoo.es>, 226609@bugs.debian.org
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 control@bugs.debian.org:
> > 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
|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
<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
<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 [~varg@pD95183C2.dip.t-dialin.net] 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 [~varg@pD95183C2.dip.t-dialin.net] 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
<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.




Reply to this item at:


  Message posté via/par Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]