Debian Bug report logs - #226609
crosshurd: Problem with much memory

version graph

Package: gnumach; Maintainer for gnumach is GNU Hurd Maintainers <debian-hurd@lists.debian.org>; Source for gnumach is src:gnumach.

Reported by: Roland Stigge <stigge@antcom.de>

Date: Wed, 7 Jan 2004 15:03:22 UTC

Severity: important

Tags: fixed-upstream, upstream

Fixed in version gnumach/1:20050801-3

Done: Guillem Jover <guillem@debian.org>

Bug is archived. No further changes may be made.

Forwarded to https://savannah.gnu.org/bugs/?func=detailitem&item_id=7118

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Jeff Bailey <jbailey@nisa.net>:
Bug#226609; Package crosshurd. Full text and rfc822 format available.

Acknowledgement sent to Roland Stigge <stigge@antcom.de>:
New Bug report received and forwarded. Copy sent to Jeff Bailey <jbailey@nisa.net>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Roland Stigge <stigge@antcom.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: crosshurd: Problem with much memory
Date: Wed, 07 Jan 2004 14:00:55 +0100
Package: crosshurd
Version: 1.5
Severity: important

Hi,

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.

Thanks for considering.

bye,
  Roland

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux atari 2.6.0 #1 Wed Dec 31 16:15:56 CET 2003 i686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (ignored: LC_ALL set to en_GB.UTF-8)

Versions of packages crosshurd depends on:
ii  dialog                   0.9b-20031207-1 Displays user-friendly dialog boxe
ii  dpkg-dev                 1.10.18         Package building tools for Debian

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Jeff Bailey <jbailey@nisa.net>:
Bug#226609; Package crosshurd. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and forwarded to list. Copy sent to Jeff Bailey <jbailey@nisa.net>. Full text and rfc822 format available.

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

From: Robert Millan <zeratul2@wanadoo.es>
To: Roland Stigge <stigge@antcom.de>, 226609@bugs.debian.org
Subject: Re: Bug#226609: crosshurd: Problem with much memory
Date: Wed, 7 Jan 2004 21:19:38 +0100
reassign 226609 gnumach
thanks

crosshurd is a package for generating base gnu tarballs. Bugs in components
of the gnu system that slip into such tarballs don't belong in this package.

Reassigning to gnumach.

On Wed, Jan 07, 2004 at 02:00:55PM +0100, Roland Stigge wrote:
> Package: crosshurd
> Version: 1.5
> Severity: important
> 
> Hi,
> 
> 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.
> 
> Thanks for considering.

-- 
Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

 -- J.R.R.T., Ainulindale (Silmarillion)



Bug reassigned from package `crosshurd' to `gnumach'. Request was from Robert Millan <zeratul2@wanadoo.es> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Hurd Maintainers <bug-hurd@gnu.org>:
Bug#226609; Package gnumach. Full text and rfc822 format available.

Acknowledgement sent to Michael Banck <mbanck@debian.org>:
Extra info received and forwarded to list. Copy sent to GNU Hurd Maintainers <bug-hurd@gnu.org>. Full text and rfc822 format available.

Message #17 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
|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



Tags added: upstream Request was from Samuel Thibault <samuel.thibault@ens-lyon.org> to control@bugs.debian.org. Full text and rfc822 format available.

Noted your statement that Bug has been forwarded to https://savannah.gnu.org/bugs/?func=detailitem&item_id=7118. Request was from Samuel Thibault <samuel.thibault@ens-lyon.org> to control@bugs.debian.org. Full text and rfc822 format available.

Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Roland Stigge <stigge@antcom.de>:
Bug acknowledged by developer. Full text and rfc822 format available.

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

From: Guillem Jover <guillem@debian.org>
To: 226609-close@bugs.debian.org
Subject: Bug#226609: fixed in gnumach 1:20050801-3
Date: Wed, 11 Jan 2006 15:32:18 -0800
Source: gnumach
Source-Version: 1:20050801-3

We believe that the bug you reported is fixed in the latest version of
gnumach, which is due to be installed in the Debian FTP archive:

gnumach-dbg_20050801-3_i386.deb
  to pool/main/g/gnumach/gnumach-dbg_20050801-3_i386.deb
gnumach-dev_20050801-3_i386.deb
  to pool/main/g/gnumach/gnumach-dev_20050801-3_i386.deb
gnumach-udeb_20050801-3_i386.udeb
  to pool/main/g/gnumach/gnumach-udeb_20050801-3_i386.udeb
gnumach_20050801-3.diff.gz
  to pool/main/g/gnumach/gnumach_20050801-3.diff.gz
gnumach_20050801-3.dsc
  to pool/main/g/gnumach/gnumach_20050801-3.dsc
gnumach_20050801-3_i386.deb
  to pool/main/g/gnumach/gnumach_20050801-3_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 226609@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated gnumach package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 12 Jan 2006 00:54:05 +0200
Source: gnumach
Binary: gnumach gnumach-dev gnumach-udeb gnumach-dbg
Architecture: source i386
Version: 1:20050801-3
Distribution: unstable
Urgency: low
Maintainer: GNU Hurd Maintainers <debian-hurd@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description: 
 gnumach    - The GNU version of the Mach microkernel
 gnumach-dbg - The GNU version of the Mach microkernel for debugging
 gnumach-dev - The GNU version of the Mach microkernel
 gnumach-udeb - The GNU version of the Mach microkernel (udeb)
Closes: 46709 226609
Changes: 
 gnumach (1:20050801-3) unstable; urgency=low
 .
   * Fix build failure with latest make 3.81 beta and the new tab vs. shell
     POSIX behaviour.
     - debian/patches/00_build_make_beta.patch: New file.
     Thanks to Alfred M. Szmidt <ams@gnu.org>.
   * Added ChangeLog entries.
     - debian/patches/13_ide_dma.patch: Modify
     - debian/patches/14_alloc_params.patch: Likewise.
   * Fix io port access. (Closes: #46709)
     - debian/patches/40_user-tss.patch: New file.
     - debian/patches/41_io_unlock_ioremove.patch: Likewise.
     - debian/patches/42_disable_ioperm.disabled: Likewise.
     - debian/patches/43_debvice_port_fix.patch: Likewise.
     - debian/patches/44_more_ports.patch: Likewise.
     - debian/patches/45_io_per_task.patch: Likewise.
     - debian/patches/46_io_device.patch: Likewise.
     Thanks to Samuel Thibault <samuel.thibault@ens-lyon.org>.
   * Fix memory limit, that was causing panics when having roughly more than
     768 MiB of physical memory. (Closes: #226609)
     - debian/patches/50_mem_limit.patch: New file.
     Thanks to Samuel Thibault <samuel.thibault@ens-lyon.org>.
Files: 
 cb832ecde64825c19694af3aedca5449 856 base optional gnumach_20050801-3.dsc
 522ca102735a7384bcc7eb3eb673c911 410106 base optional gnumach_20050801-3.diff.gz
 bfbd5bf5a04c35a90169a1ac62819f21 966390 base optional gnumach_20050801-3_i386.deb
 520c2de5ad1708b636f90ccf647f3901 820402 debian-installer optional gnumach-udeb_20050801-3_i386.udeb
 e6e69d8477ff27c04eaadba586537df7 3117994 devel extra gnumach-dbg_20050801-3_i386.deb
 023431df46072a10ec3f86b3ac59f510 130864 devel optional gnumach-dev_20050801-3_i386.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDxZBVuW9ciZ2SjJsRAswPAJ9Dbmj/5uG9GXozLBy2uXcWL0H8pQCeIn5n
6xIX9OXh0icVEtAo4UffTVo=
=Ml3e
-----END PGP SIGNATURE-----




Tags added: fixed-upstream Request was from bts-link-upstream@lists.alioth.debian.org to control@bugs.debian.org. Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 24 Jun 2007 13:09:07 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 16:22:52 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.