Pid 1 crashing under L4Linux
adam at os.inf.tu-dresden.de
Wed Jul 9 00:38:21 CEST 2014
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
> 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
> 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?
You can also add "print-fatal-signals=1" to get to know the actual
address that faulted.
Adam adam at os.inf.tu-dresden.de
More information about the l4-hackers