l4lx_memory_map_virtual_page messages ending in internal error

[Uwe Geuder]

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 at nomovok.com (bot test: humans correct 1 obvious spelling error)