Hi!
On Fri Jul 11, 2014 at 19:52:29 +0300, Uwe Geuder wrote:
As mentioned in a previous thread I tried xz compression of my initramfs image in L4Linux on ARM. When L4Linux tried to decompress the following messages occured:
Trying to unpack rootfs image as initramfs... l4lx_memory_map_virtual_page: Already used, existing is 2400020 l4lx_memory_map_virtual_page: cannot attach vpage (2ca64000, 2816324f): -99 l4lx_memory_map_virtual_page: Already used, existing is 2400020
and the same messages (with increasing address) repeated for a zillion of times until it eventually ended like this:
On Mon, 14 Jul 2014 23:46:11 +0200, Adam Lackorzynski wrote:
How much memory did you give L4Linux and how big is the initrd (compressed and uncompressed)?
The device has 1 GB of RAM. L4Linux is configured with mem=650M. The initramfs is about 260 MB uncompressed, around 70 MB xz compressed.
Originally I tried with xz options not ideal for the puprpose, so uncompression of the image would have required 65 MB of memory. Still that's only 10% of the memory assgined to L4Linux, I am quite sure there is plenty of free memory around. Well, with 2 reservations.
- The data about how much memory is needed for uncompression is reported by xz -l on the host, the kernel uses XZ embedded. Still I would find it suprising if the xz embedded implementation required more memory than the full size implementation.
- And I don't know from which pool the kernel allocates memory when uncompressing initramfs. Could that be a pool with much lower limit than the full 650 MB?
I still repeated the exercise twice. First with the xz options given in the kernel source. Unompression of that image is reported to take 33 MB of memory. Then I tried once more with even mored restrictive options, so that the image can be uncomressed with 17 MB of memory. The error messages were the same in all cases. I had the feeling that for the image requiring less memory for uncompression the l4lx_memory_map_virtual_page error was repeated less often than for the originak image. However, I did not count. (I could still do that, if it is valuable information.)
Regards,
Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder@nomovok.com (bot test: humans correct 1 obvious spelling error)