Kernel Panic related to init usage????

Stephen Beckwith embeddedsteve at gmail.com
Wed Mar 11 20:15:21 UTC 2015


Greetings,
   Please forgive the long-winded e-mail, but as a fellow developer, the
more you know, the easier/quicker you can reach some sort of conclusion
with my problem here.
   Where I work we have an existing "home grown" system for x86 based
systems.  The target system is considered "embedded" (no video output, no
graphics, just lots of other high speed I/O going on).  The existing system
was build around a RHEL 5 based setup, where it's "required" that you
compile on this specific host, since they "borrow" libraries and other
applications from the host to create the target RFS.  (yea, quite wrong. .
.).  Mind you, this is code that's not been touched in 3+ years, and I just
started here 4 months ago. So the current setup:

Kernel is 2.6.32 vintage with busy box 1.19.1.  Builds OK, fine, boots on
the target HW and all, find, not a problem.  This is the basis for a
hardware based tool used by HW engineers/manufacturing to checkout new HW
systems, so it's talking to all the various chips/boards in the system.
This is all working, mostly. (some components are being brought up to date
for newer chips, etc).

However, since this is truly an "old" kernel, we need to support some 3rd
party tools that require newer (> 3.4.x) kernel versions.  The vendors
won't support the older kernel (who would!).  Therefore, I've taken the
initiative to bring things up to date.

Step 1 was to build the test application on a newer host system, with the
old kernel, BB, etc.  The host is FedoraCore21, LXDE spin running in
VirtualBox on my MacBookPro.   There were some tweaks done to the busy box
source, related to kernel header files that were moved or made obsolete.
The changes ended up, mostly in the libbb.h file.  AND, since the host is a
much newer compiler, I also needed to correct all of the warnings that now
pop as errors with the more picky compiler in the application source (which
is user space apps + kernel modules/drivers for the chips).  This
eventually was successfully booted on the new target hardware successfully
and ran just fine.

Step 2 was to introduce a new kernel.  For this, I used a 3.18.4 from
kernel.org.  Re-used the old kernel configuration and it built OK. There
are some issues related to some header files that are preventing the
application from building, so I've disabled this for now.  So what I'm
building is:  kernel, busy box, dropbear;  this gets wrapped up in a
initramfs and the output we boot is a bzImage.  This is all RAM based
execution, since we have not "permanent" storage available to us on the
platform.
This kernel seems to boot OK, to the point of starting up the init process:

Linux version 3.18.4 (sbeckwith at localhost.localdomain) (gcc version 4.9.2
20150212 (Red Hat 4.9.2-6) (GCC) ) #2 SMP Mon Mar 9 16:48:10 EDT 2015
I see the "Freeing kernel memory. . . . " line, then I get a kernel panic.
This is preceded by the following "help" message:

Usage: init [options] [mask | cpu-list] [pid|cmd [args...]]


Options:

 -a, --all-tasks         operate on all the tasks (threads) for a given pid

 -p, --pid               operate on existing given pid

 -c, --cpu-list          display and specify cpus in list format

 -h, --help              display this help

 -V, --version           output version information


The default behavior is to run a new command:

    init 03 sshd -b 1024

You can retrieve the mask of an exisSwitched to clocksource tsc

ting task:

    init -p 700

Or set it:

    init -p 03 700

List format uses a comma-separated list instead of a mask:

    init -pc 0,3,7-11 700

Ranges in list format can take a stride argument:

    e.g. 0-31:2 is equivalent to mask 0x55555555


For more information see taskset(1).
I assume this is from BusyBox.
taskset() is configured to be part of busy box, per the configuration I
generated.
yes, this is a multi-core Intel part.

The kernel panic:

Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100


CPU: 1 PID: 1 Comm: init Not tainted 3.18.4.#2

Hardware name:

 ffff881058b69140 ffff8810989cbe18 ffffffff817c7712 0000000000001815

 ffffffff81a7a8d0 ffff8810989cbe98 ffffffff817c4fcf 00000001989cbe98

 ffffffff00000010 ffff8810989cbea8 ffff8810989cbe48 ffff881058b69140

Call Trace:

 [<ffffffff817c7712>] dump_stack+0x46/0x58

 [<ffffffff817c4fcf>] panic+0xbb/0x1e9

 [<ffffffff8104ee02>] do_exit+0xac2/0xad0

 [<ffffffff811b16a2>] ? __close_fd+0x22/0xa0

 [<ffffffff8104fdfe>] do_group_exit+0x4e/0xc0

 [<ffffffff8104fe84>] SyS_exit_group+0x14/0x20

 [<ffffffff817cff92>] system_call_fastpath+0x12/0x17

Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range:
0xffffffff80000000-0xffffffff9fffffff)

---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000100

So, knowing newer kernels are moving to FDT's and systemd, I figured I'll
update BusyBox as well. . .
So I downloaded and installed BB 1.23.1 into the build system.  After
running the old configuration through a "make menuconfig" and turning off
systemd, I saved the config file for building.  Everything builds OK and I
get my bzImage output.  Size is ~ what I'd expect, minus the application.
(the bzImage is ~ 42MB).
However, this again failed, in exactly the same way:  same error message,
same dump, etc.

The current "init" setup is just an init.d directory with a few scripts to
startup/load "standard" modules, and the specific application ones we
want.  In root, there is a /init -> /bin/busybox link.  The inittab first
entry is:  ::sysinit:/etc/init.d/rcS
I've added an "echo" @ the start of the rcS script to see if I get there
and I don't. (at least it's not printed. . .)

So my questions are:
1) IS this Usage message coming from the busy box "init" ????
2) does busy box work with a 3.18.4 kernel?
3) what changed that now INIT requires parameters?
4) Any pointers one can provide to the necessary changes, since my
"template" is the FC21 host, and it's using systemd.

Google has not been my friend, I can't seem to formulate the question
correctly to get any answers.
Your expertise is greatly appreciably.

Regards,
Stephen Beckwith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20150311/17cc39e3/attachment-0001.html>


More information about the busybox mailing list