On Thu, Sep 25, 2025 at 11:12:34PM +0100, João Pedro Malhado wrote: > As Mike has outline recently, if a system has 1 GB of RAM one will end up > with a > 141MB highmem segment. This prevents booting the hurd with rumpdisk as he > described, but the problems run deeper than that. Even booting the system > using > the ide drivers in gnumach, the system is sluggish, takes a long time to > perform > certain tasks, and can become unresponsive. The system becomes unresponsive > for example while upgrading the hurd package, which while setting up the > translators launches rumpdisk (I think because of the detected USB ports). I > don't think this is related to rumpdisk per se, but how gnumach is managing > memory. > In comparison, a laptop with 512MB of RAM runs much more smoothly than one > with > 1024MB! > Is this because only the highmem segment with 141MB is being used for the > user space? > It was mentioned that it is not worth investing time in fixing the 32bit > kernel, > but I wonder if there is some sort of workaround. Is it possible to limit the > amount of memory that is "shown to" gnumach such that it maps only the > directmap > segment and ignores the extra 141MB? Reading some old documentation I > saw the uppemem option in grub, but this did not change anything (or I did not > use it correctly). > Is there a gnumach boot option that would work like mem=XX in linux? > Or would anyone be able to suggest a patch for gnumach to just ignore the > highmem segment which I could apply?
Hello, This list is for Debian-specific issues. A kernel issue such as this is best discussed on [email protected]. -- Richard Braun
