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

[Stefan Weil <sw@weilnetz.de>]

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