qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] qemu-m68k: add support for interrupt masking


From: Stefan Weil
Subject: Re: [Qemu-devel] [PATCH v2] qemu-m68k: add support for interrupt masking/unmasking
Date: Fri, 03 Apr 2015 10:27:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0

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.

Regards
Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]