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 _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
