Hi!
I'm pretty new to L4 so I hope this is not an FAQ. I tried to search the forum archives but couldn't find an answer.
I'm using L4 on an i.MX6 device. Building fiasco, L4Re and L4Linux succeeded without any errors as far as I can tell. A small ramdisk containing busybox works fine and I can play around on the command line. (The system actually has framebuffer support, so I can even get something on the screen.)
Now I replaced the small "demo" ramdisk by one containing a bigger distro. This bigger ramdisk runs without problems on a native Linux kernel.
However, on L4Linux I always get
RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 262144KiB [1 disk] into ram disk... EXT4-fs (ram0): couldn't mount as ext3 due to feature incompatibilities EXT4-fs (ram0): couldn't mount as ext2 due to feature incompatibilities EXT4-fs (ram0): mounted filesystem with ordered data mode. Opts: (null) VFS: Mounted root (ext4 filesystem) readonly on device 1:0. Freeing unused kernel memory: 116K (022f9000 - 02316000) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
CPU: 0 PID: 1 Comm: sh Not tainted 3.14.0-l4 #7 [<0200c47c>] (unwind_backtrace) from [<02005618>] (show_stack+0x10/0x14) [<02005618>] (show_stack) from [<02238d08>] (panic+0x8c/0x1c8) [<02238d08>] (panic) from [<020186bc>] (complete_and_exit+0x0/0x1c) [<020186bc>] (complete_and_exit) from [<00000001>] (0x1) panic: going to sleep forever, bye l4linux | panic: going to sleep forever, bye
The stack trace is the same for init=/bin/sh and the default systemd. Looks like for some reason user space processes in this setup just crash pretty soon.
The console log before that looks pretty unsuspicious to me. But I can of course post it should it be necessary to understand what is going on.
What comes to my mind is that my user space is built for armv7tnhl, i. e. thumb instruction set, NEON, and hard-float.
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb
Can any of these options be a problem under L4?
(The small busybox ramdisk, which works fine was built by a colleague of mine who is on holidays at the moment. I'm not sure how he built it, but I assume it's neither hard-float nor thumb. Well, I could disassemble something to be sure I guess...)
If armv7tnhl does not cause obvious problems, do you have any debugging hints/pointers how to find out why/where pid 1 is crashing? Address 0x1 is nonsense I suppose, but if tells anything then that the processor is in thumb mode. Which is what I would expect from my user space.
Regards,
Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder@nomovok.com (bot test: humans correct 1 obvious spelling error)
Hi,
On Wed Jul 09, 2014 at 01:23:52 +0300, Uwe Geuder wrote:
I'm pretty new to L4 so I hope this is not an FAQ. I tried to search the forum archives but couldn't find an answer.
I'm using L4 on an i.MX6 device. Building fiasco, L4Re and L4Linux succeeded without any errors as far as I can tell. A small ramdisk containing busybox works fine and I can play around on the command line. (The system actually has framebuffer support, so I can even get something on the screen.)
Now I replaced the small "demo" ramdisk by one containing a bigger distro. This bigger ramdisk runs without problems on a native Linux kernel.
However, on L4Linux I always get
RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 262144KiB [1 disk] into ram disk... EXT4-fs (ram0): couldn't mount as ext3 due to feature incompatibilities EXT4-fs (ram0): couldn't mount as ext2 due to feature incompatibilities EXT4-fs (ram0): mounted filesystem with ordered data mode. Opts: (null) VFS: Mounted root (ext4 filesystem) readonly on device 1:0. Freeing unused kernel memory: 116K (022f9000 - 02316000) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
CPU: 0 PID: 1 Comm: sh Not tainted 3.14.0-l4 #7 [<0200c47c>] (unwind_backtrace) from [<02005618>] (show_stack+0x10/0x14) [<02005618>] (show_stack) from [<02238d08>] (panic+0x8c/0x1c8) [<02238d08>] (panic) from [<020186bc>] (complete_and_exit+0x0/0x1c) [<020186bc>] (complete_and_exit) from [<00000001>] (0x1) panic: going to sleep forever, bye l4linux | panic: going to sleep forever, bye
The stack trace is the same for init=/bin/sh and the default systemd. Looks like for some reason user space processes in this setup just crash pretty soon.
The console log before that looks pretty unsuspicious to me. But I can of course post it should it be necessary to understand what is going on.
What comes to my mind is that my user space is built for armv7tnhl, i. e. thumb instruction set, NEON, and hard-float.
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb
Can any of these options be a problem under L4?
(The small busybox ramdisk, which works fine was built by a colleague of mine who is on holidays at the moment. I'm not sure how he built it, but I assume it's neither hard-float nor thumb. Well, I could disassemble something to be sure I guess...)
If armv7tnhl does not cause obvious problems, do you have any debugging hints/pointers how to find out why/where pid 1 is crashing? Address 0x1 is nonsense I suppose, but if tells anything then that the processor is in thumb mode. Which is what I would expect from my user space.
None of those points should be any problem. Are all enabled? CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_NEON=y CONFIG_ARM_THUMB=y
You can also add "print-fatal-signals=1" to get to know the actual address that faulted.
Adam
Hi!
Thanks a lot for your quick reply!
On Wed, 9 Jul 2014 00:38:21 +0200, Adam Lackorzynski wrote:
On Wed Jul 09, 2014 at 01:23:52 +0300, Uwe Geuder wrote:
I'm pretty new to L4 so I hope this is not an FAQ. I tried to search the forum archives but couldn't find an answer.
I'm using L4 on an i.MX6 device. Building fiasco, L4Re and L4Linux succeeded without any errors as far as I can tell. A small ramdisk containing busybox works fine and I can play around on the command line. (The system actually has framebuffer support, so I can even get something on the screen.)
Now I replaced the small "demo" ramdisk by one containing a bigger distro. This bigger ramdisk runs without problems on a native Linux kernel.
However, on L4Linux I always get
RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 262144KiB [1 disk] into ram disk... EXT4-fs (ram0): couldn't mount as ext3 due to feature incompatibilities EXT4-fs (ram0): couldn't mount as ext2 due to feature incompatibilities EXT4-fs (ram0): mounted filesystem with ordered data mode. Opts: (null) VFS: Mounted root (ext4 filesystem) readonly on device 1:0. Freeing unused kernel memory: 116K (022f9000 - 02316000) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
CPU: 0 PID: 1 Comm: sh Not tainted 3.14.0-l4 #7 [<0200c47c>] (unwind_backtrace) from [<02005618>] (show_stack+0x10/0x14) [<02005618>] (show_stack) from [<02238d08>] (panic+0x8c/0x1c8) [<02238d08>] (panic) from [<020186bc>] (complete_and_exit+0x0/0x1c) [<020186bc>] (complete_and_exit) from [<00000001>] (0x1) panic: going to sleep forever, bye l4linux | panic: going to sleep forever, bye
The stack trace is the same for init=/bin/sh and the default systemd. Looks like for some reason user space processes in this setup just crash pretty soon.
The console log before that looks pretty unsuspicious to me. But I can of course post it should it be necessary to understand what is going on.
What comes to my mind is that my user space is built for armv7tnhl, i. e. thumb instruction set, NEON, and hard-float.
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb
Can any of these options be a problem under L4?
(The small busybox ramdisk, which works fine was built by a colleague of mine who is on holidays at the moment. I'm not sure how he built it, but I assume it's neither hard-float nor thumb. Well, I could disassemble something to be sure I guess...)
If armv7tnhl does not cause obvious problems, do you have any debugging hints/pointers how to find out why/where pid 1 is crashing? Address 0x1 is nonsense I suppose, but if tells anything then that the processor is in thumb mode. Which is what I would expect from my user space.
None of those points should be any problem. Are all enabled? CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_NEON=y CONFIG_ARM_THUMB=y
Indeed, VFP and its suboptions were not enabled. After enabling them /bin/sh runs fine as PID 1. Systemd doesn't crash either anymore, but still doesn't work. Probably some kernel options required by systemd still missing, need to check the systemd documentation.
You can also add "print-fatal-signals=1" to get to know the actual address that faulted.
Yes, that tells me that the problem was illegal instruction and also some pointers. Did not check what they point to (or whether they are helpful at all), because the problem is already solved. Good to know for the next time.
< Freeing unused kernel memory: 116K (022f9000 - 02316000) < potentially unexpected fatal signal 4. < < CPU: 0 PID: 1 Comm: sh Not tainted 3.14.0-l4 #11 < task: 2a03ba40 ti: 2a03c000 task.ti: 2a03c000 < PC is at 0xb7ae7078 < LR is at 0xb7ae3d1f < pc : [<b7ae7078>] lr : [<b7ae3d1f>] psr: 00000030 < sp : bf9f2c58 ip : 00000000 fp : 00000000 < r10: 00020234 r9 : 00000000 r8 : 00000000 < r7 : 00000000 r6 : 00000000 r5 : 00000000 r4 : 00000948 < r3 : 00000000 r2 : 00000000 r1 : 0001cf2a r0 : bf9f2f00 < vcpu: b3000c00 vcpu-state: 00000001 < Flags: nzcv IRQs on FIQs on Mode USER_32 ISA Thumb Segment user < CPU: 0 PID: 1 Comm: sh Not tainted 3.14.0-l4 #11 < [<0200c47c>] (unwind_backtrace) from [<02005618>] (show_stack+0x10/0x14) < [<02005618>] (show_stack) from [<02022fb0>] (get_signal_to_deliver+0x240/0x4cc) < [<02022fb0>] (get_signal_to_deliver) from [<02006bb8>] (do_signal+0x118/0x464) < [<02006bb8>] (do_signal) from [<02006f78>] (do_work_pending+0x74/0xbc) < [<02006f78>] (do_work_pending) from [<0200867c>] (l4x_pre_iret_work.isra.31.part.32+0x60/0x104) < [<0200867c>] (l4x_pre_iret_work.isra.31.part.32) from [<02009624>] (l4x_vcpu_entry_c+0x224/0x1bfc) < [<02009624>] (l4x_vcpu_entry_c) from [<b7ae3d1f>] (0xb7ae3d1f) < Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 < < CPU: 0 PID: 1 Comm: sh Not tainted 3.14.0-l4 #11 < [<0200c47c>] (unwind_backtrace) from [<02005618>] (show_stack+0x10/0x14) < [<02005618>] (show_stack) from [<02238d08>] (panic+0x8c/0x1c8) < [<02238d08>] (panic) from [<020186bc>] (complete_and_exit+0x0/0x1c) < [<020186bc>] (complete_and_exit) from [<00000001>] (0x1) < panic: going to sleep forever, bye < l4linux | panic: going to sleep forever, bye <
Thanks again,
Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder@nomovok.com (bot test: humans correct 1 obvious spelling error)
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Uwe Geuder