Re: [Xenomai-help] Kernel panic: not syncing

[Jan Kiszka <jan.kiszka@domain.hid>]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Petr Cervenka wrote:
>>>> Hello,
>>>> I'm not sure if I'm not off topic.
>>>> We use Linux 2.6.24 and Xenomai 2.4.1. Occasionally (once in few
>>>> days) we get an kernel panic and I don't know If it's our fault or a
>>>> problem of kernel/xenomai/adeos/configuration/hw/...
>>>> If you have any questions, i'll try to answer them. Any help is
>>>> welcome.
>>> It is an I-pipe issue, probably. We have to somewhat forge the
>>> register frame
>>> passed to the Linux tick handler, since we may delay that call. Some
>>> register
>>> values the profiling code attempts to dereference to find the
>>> preempted code may
>>> be wrong in our case.
>>>
>>> Could you 1) send back a disassembly of the profile_tick routine in
>>> your kernel
>>> image, then apply the following patch to check whether it improves
>>> the situation
>>> as well? TIA,
>>>
>>> --- 2.6.24-x86-2.0-03/arch/x86/kernel/ipipe.c~    2008-02-11
>>> 10:48:24.000000000 +0100
>>> +++ 2.6.24-x86-2.0-03/arch/x86/kernel/ipipe.c    2008-07-07
>>> 17:55:36.000000000 +0200
>>> @@ -933,12 +933,7 @@
>>>          tick_regs->eip = regs.eip;
>>>          tick_regs->ebp = regs.ebp;
>>>  #else /* !CONFIG_X86_32 */
>>> -        tick_regs->ss = regs->ss;
>>> -        tick_regs->rsp = regs->rsp;
>>> -        tick_regs->eflags = regs->eflags;
>>> -        tick_regs->cs = regs->cs;
>>> -        tick_regs->rip = regs->rip;
>>> -        tick_regs->rbp = regs->rbp;
>>> +        *tick_regs = *regs;
>>>  #endif /* !CONFIG_X86_32 */
>>
>> I'm fairly sure that this won't make a difference. According to Petr's
>> first dump we crash in profile_pc, and there the kernel pokes around on
>> the stack of the interrupted context (Petr, you are running SMP,
>> right?). The question is if this stack may have vanished or may have
>> been swapped out after capturing the registers.
> 
> When Xenomai has forwarded the tick to linux, Linux tick handler is
> executed upon resume to user-space, so, if the stack had to vanish, it
> would have to vanish upon execution of another interrupt handler before
> the tick handler. However, I believe that only do_exit can kill a task,
> and I am not sure if it can be called from an interrupt handler. As for
> the stack being swapped out, it is kmalloced memory, so, it is impossible.
> 

Yes, vanishing stack is unlikely, more probable is an invalid state
right from the beginning. I guess we need a full oops to say more.

Petr, any chance to attach a serial cable to your box and catch those
oopses completely via a second box? The register state would be telling,
but also, as Philippe already requested, a disassembly of the involved
function - in case it remain profile_pc: objdump -dS
linux-.../arch/x86/kernel/time_64.o.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux