Hello everyone, 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?
Regards, João
