bugThe GNU Hurd - Bugs: bug #7118, GNU Mach can't handle 1G memory

 
 

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

Submitter:  None
Submitted:  Wed 07 Jan 2004 07:37:04 AM UTC
   
 
Category:  GNU Mach Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Hardware Support
Status:  Fixed Privacy:  Public
Assigned to:  tschwinge Originator Name: 
Originator Email:  -email is unavailable- Open/Closed:  Closed
Reproducibility:  Every Time Size (loc):  None
Planned Release:  GNU Mach 1.4 Effort:  0.00
Wiki-like text discussion box: 


* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 08 May 2006 10:06:15 PM UTC, comment #4: 

I committed the following:

2006-05-08  Thomas Schwinge  <tschwinge@gnu.org>

  • DEVELOPMENT: Document Samuel's patch.


2006-05-08  Samuel Thibault  <samuel.thibault@ens-lyon.org>

  • i386/i386at/model_dep.c (mem_size_init): Limit memory to what can

actually be used (minus a little extra for virtual mappings).

  • i386/intel/pmap.c (pmap_bootstrap): Extend the virtual mapping area

according to memory size for at least being able to manage it.  But
look out for wrap and limit it to kernel adresses.  Remove duplicate
computing.


Thanks for your contribution!

Thomas Schwinge <tschwinge>
Group administrator
Sun 08 Jan 2006 11:42:10 PM UTC, comment #3: 

Hi,

There were two problems, which the attached patch addresses.

- The area for kernel mappings was limited to an arbitrary limit of 40MB. This is enough for managing up to ~700MB, but not more (because of some memory management structures), so I extended this area according to the memory size.
- Since it maps all physical memory in the kernel space, gnumach can't handle more than 1GB of memory on i386 (VM_MAX_KERNEL_ADDRESS) (just like linux on x86 without high memory support). Plus we need room for kernel mappings, which can be as much as 1/15 of the GB, so reserve that. Hence gnumach can't use more than 960MB.

With the patch applied, I could boot fine with more than 1GB of memory.

Regards,
Samuel

Samuel Thibault <sthibaul>
Group administrator
Sat 31 Dec 2005 11:44:49 AM UTC, comment #2: 

Can also be reproduced in qemu by setting the amount of avaiable memory to >= 1GiB.

Alfred M. Szmidt <ams>
Mon 26 Dec 2005 09:08:10 PM UTC, comment #1: 

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

Message received at -email is unavailable- (full text, mbox):

From: Michael Banck <mbanck@debian.org>
To: Robert Millan <zeratul2@wanadoo.es>, -email is unavailable-
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
|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 [~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
        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

Samuel Thibault <sthibaul>
Group administrator
Wed 07 Jan 2004 07:37:04 AM UTC, original submission:  

If you have 1G memory or more, GNU Mach can't run.

Workaround is adding the following command to Hurd's entry in Grub's menu.lst:

[title GNU/Hurd]
uppermem 524288
[kernel...]
[module...]

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #2218:  patch-gnumach-maxmem added by sthibaul (2KiB - application/octet-stream - Fix for machines with more than 700MB and 1GB)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 7 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-05-08 tschwinge StatusConfirmed Fixed
    Open/ClosedOpen Closed
2006-05-08 tschwinge Item GroupNone Hardware Support
    Assigned toNone tschwinge
    Planned ReleaseNone GNU Mach 1.4
2006-01-08 sthibaul Attached File- Added patch-gnumach-maxmem, #3260
2005-12-31 ams StatusNone Confirmed

Back to the top

Powered by Savane 3.13-f8d8.
Corresponding source code