Hi!
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:
l4lx_memory_map_virtual_page: cannot attach vpage (2ee44000, 25d4324f): -99 l4linux | Non-resolvable page fault at 2ca64003, ip 2168884. l4linux | Page fault (non-resolved): pfa=2ca64003 pc=2168884 Unable to handle kernel paging request at virtual address 2ca64000 pgd = 0234b000 [2ca64000] *pgd=25d51811, *pte=2816324f, *ppte=00000000 Internal error: Oops: 410807 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.0-l4 #14 task: 2a03ba40 ti: 2a03c000 task.ti: 2a03c000 PC is at dict_repeat.part.5+0x58/0x90 LR is at lzma_main+0x984/0x990 pc : [<02168884>] lr : [<02169240>] psr: 20000013 sp : 2a03dd4c ip : 01c1f000 fp : 04205590 r10: 00000003 r9 : 00000005 r8 : 2a12eee8 r7 : 00006ee4 r6 : 00000000 r5 : 2a03ddf8 r4 : 2ae45000 r3 : 00000042 r2 : 00000000 r1 : 01c1f000 r0 : 2a128018 vcpu: b3000c00 vcpu-state: 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Process swapper (pid: 1, stack limit = 0x2a03c238) Stack: (0x2a03dd4c to 0x2a03e000) dd40: 2a128000 00000002 00000000 25eb0548 32e00000 dd60: 00000000 2a128000 2a03ddf8 00000000 00006ee4 2a12eee8 00000005 00000003 dd80: 04205590 021698e4 00000000 002457cc 00000000 00000003 00000000 2a03ddf8 dda0: 2a0ec000 00000003 00000001 021681d4 02321480 02309f44 02321480 02321480 ddc0: 00001000 002457cc 00001000 00000000 00001000 00000000 02350054 02309cd4 dde0: 2a0ec000 00000000 00000000 32e00000 00000000 02317cdc 32e00000 002457cc de00: 0444ad5c 2a0c7000 00000000 00001000 00000005 00000000 00000000 0444ad5c de20: 32e00000 02321480 02321480 02350054 02309b64 0230a0f4 00000000 02350054 de40: 02309b64 0230a670 00000000 00000000 0235004c 022cb7d0 022b4b24 02326db8 de60: 02350050 00000000 02350000 0230a670 0000003d 02350050 0235004c 0230a6e4 de80: 0000000a 00000000 023462a0 0231fee4 00000000 02249f60 00000005 02349a60 dea0: 00000000 021c9620 2a03ba40 02349a60 02349a60 02350000 02346284 02346284 dec0: 02353b0c 02346284 00000000 02326bcc 00000005 02350000 02350000 0230a670 dee0: 0000003d 2a03c030 00000000 02000444 0224f3c0 020da7d8 0233d430 022bd31c df00: 2a05f800 0224f3c0 000000db 00000000 00000000 00000005 023357fc 00000001 df20: 2a899e3b 0225af94 0000003d 02032e5c 022f16d8 00000005 2a899e50 00000005 df40: 023357f0 02326bcc 00000005 02350000 02350000 0230819c 0000003d 02321400 df60: 023213f0 02308880 00000005 00000005 0230819c 0233e900 2a03b700 00000001 df80: 00000000 00000000 02243ed8 00000000 00000000 00000000 00000000 00000000 dfa0: 00000000 02243ee0 00000000 02007da8 00000000 00000000 00000000 00000000 dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<02168884>] (dict_repeat.part.5) from [<00000002>] (0x2) Code: e281c001 e580c008 e282c001 e7d42002 (e7c42001) ---[ end trace 0aaf617cdd732ae2 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
panic: going to sleep forever, bye l4linux | panic: going to sleep forever, bye
What can I learn from these messages? The same image could be decompressed on the same hardware with a native Linux kernel. I know that my compression options were probably not optimal and the algorithm might have used a lot of memory. But I have seen out of memory messages from Moe and L4Linux before and they were easy to understand. So could this really be some time of internal error, i.e. bug?
Regards,
Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder@nomovok.com (bot test: humans correct 1 obvious spelling error)
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:
How much memory did you give L4Linux and how big is the initrd (compressed and uncompressed)?
Adam
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)
On Wed Jul 16, 2014 at 00:51:01 +0300, Uwe Geuder wrote:
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.
That's impressively large.
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 think there's no such limit.
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.)
I suppose it works with a smaller xz-initrd? If you play a bit with the vmalloc= parameter, does it change behavior (including amount of those errors printed)? Maybe vmalloc=300m could be a start.
Adam
On Thu, 17 Jul 2014 23:06:10 +0200, Adam Lackorzynski wrote:
If you play a bit with the vmalloc= parameter, does it change behavior
Thanks for the reply again. I'll leave for holidays later today. I'll play again with those issues in about 4 weeks :)
Regards,
Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder at nomovok.com (bot test: humans correct 1 obvious spelling error)
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Uwe Geuder