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

 
 

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

Submitted by:  None
Submitted on:  Wed 07 Jan 2004 07:37:04 AM UTC  
 
Category: GNU MachSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Hardware Support
Status: FixedPrivacy: Public
Assigned to: Thomas Schwinge <tschwinge>Originator Name: 
Originator Email: -unavailable-Open/Closed: Closed
Reproducibility: Every TimeSize (loc): None
Planned Release: GNU Mach 1.4Effort: 0.00
Wiki-like text discussion box: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project AdministratorIn charge of this item.
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>
Project Member
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 -unavailable- (full text, mbox):

From: Michael Banck <mbanck@debian.org>
To: Robert Millan <zeratul2@wanadoo.es>, -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>
Project Member
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 File(s):
   
   
Comment:
   

Attached Files
file #2218:  patch-gnumach-maxmem added by sthibaul (2kB - 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

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 7 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Mon 08 May 2006 10:06:15 PM UTCtschwingeStatusConfirmed=>Fixed
  Open/ClosedOpen=>Closed
Mon 08 May 2006 04:07:09 PM UTCtschwingeItem GroupNone=>Hardware Support
  Assigned toNone=>tschwinge
  Planned ReleaseNone=>GNU Mach 1.4
Sun 08 Jan 2006 11:42:10 PM UTCsthibaulAttached File-=>Added patch-gnumach-maxmem, #3260
Sat 31 Dec 2005 11:44:49 AM UTCamsStatusNone=>Confirmed

Back to the top


Powered by Savane 3.1-cleanup