Hi Stefan, Stefan Weil wrote, > Am 03.04.2015 um 10:04 schrieb Waldemar Brodkorb: > >Hi Stefan, > >Stefan Weil wrote, > > > >>Am 29.03.2015 um 17:53 schrieb Stefan Weil: > >>>Am 29.03.2015 um 15:47 schrieb Waldemar Brodkorb: > >>>>Hi Stefan, > >>>>Stefan Weil wrote, > >>>> > >>>>>You can debug the kernel panic by attaching a cross debugger to the > >>>>>running kernel. > >>>>>If you have a kernel image with debug symbols, this is very > >>>>>comfortable. > >>>>How would I do this? > >>>>Tried to start qemu with -s -S and then attach with my cross-gdb > >>>>using the kernel with debug symbols. But gdb does not recognize the > >>>>panic: > >>>>Command: mdev -s > >>>>Command: ifconfig lo 127.0.0.1 up > >>>>Execution Finished, Exiting > >>>> > >>>>Sash command shell (version 1.1.1) > >>>>/> Kernel panic - not syncing: Attempted to kill init! > >>>>exitcode=0x0000000b > >>>> > >>>>---[ end Kernel panic - not syncing: Attempted to kill init! > >>>>exitcode=0x0000000b > >>Is this the kernel panic which you get? I did not have a closer look > >>on it before, but now I see that it is something quite common: > >> > >>Your kernel runs an init script (or binary) which terminates > >>(obviously normally). Then the kernel does not know what to > >>do, so it throws a kernel panic "Attempted to kill init". > >> > >>Usually the init process should only terminate at a system shutdown. > >The init is a simple C programm called simpleinit. > >The strange thing is, why it only happens with the ull version > >of qemu and not with the other one? > >http://www.openadk.org/cgi-bin/gitweb.cgi?p=openadk.git;a=blob;f=package/simpleinit/src/simpleinit.c;h=291f88f479cf9ad4e24d727bc09120d0e6739ac3;hb=HEAD > > > >best regards > > Waldemar > > Do you see any console output from that init process? > Can you build it with the DEBUGGING macro included? > > There is one program exit without a log message in > function read_inittab: > > if (numcmd == 0) > _exit(1); > > Add a printf or an err call there, too. Add also some log > messages in main. main includes an endless for loop, > so that init program is supposed to run without > termination. By additional log messages, it should > be possible to see why it terminates nevertheless. > > As soon as the point of termination is known, we can > think of the relation to the ULL postfix.
Shell invoked to run file: /etc/rc Sash command shell signal handler Command: echo Starting OpenADK Starting OpenADK Command: hostname openadk Command: mount -t proc proc /proc Command: mount -t sysfs sys /sys Command: mkdir -m 755 /dev/pts Command: mount -t devpts devpts /dev/pts Command: mount -t tmpfs -o size=8M tmpfs /tmp Command: chmod 1777 /tmp Command: mkdir -p /var/log Command: mkdir -p /var/run Command: mkdir -p /var/tmp Command: mdev -s Command: ifconfig lo 127.0.0.1 up Execution Finished, Exiting Sash command shell exit with 0 toks= -/bin/sh (null) tty= console termcap= linux init: main loop Sash command shell (version 1.1.1) Sash command shell signal handler /> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b The code execution path is, kernel exec simpleinit and simpleinit exec sash. After the second call to sash, when /etc/rc is finished, 2-3 seconds later the kernel panic's. I had a similar issue once I have used busybox hush instead of sash. The switching to sash fixed the issue for me and now when adding ull it happens again. Sash code ( i added some printf locally ) http://www.openadk.org/cgi-bin/gitweb.cgi?p=openadk.git;a=tree;f=package/sash/src;h=476c254af2fb4c211d32d9418807736970fbb536;hb=HEAD Discussion about the issue with hush: http://lists.busybox.net/pipermail/busybox/2014-September/081634.html best regards Waldemar
