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

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

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. Or the test
"!user_mode(regs) && in_lock_functions(pc)" returns an invalid result
(Petr, do you run Xenomai kernel tasks?).

I do not yet see the scenario behind it, but a workaround for a
vanishing stack could be to cache sp[0] and sp[1] (as accessed in
profile_pc) and let a faked regs->rsp point to that cache. Nevertheless,
understanding the actual reason should remain a goal at the same time
(to avoid papering over an even more serious issue).

Jan

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