Kernel panic: not syncing
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.
Petr Cervenka
I will try to reproduce the log (visible part of it). I can mail you snapshots for details, if needed:
---------------------------------------------------------------
<IRQ> profile_tick+0x5e/0xa0 tick_sched_timer+0x85/0x170 hrtimer_interrupt+0x12f/0x1e0 smp_apic_timer_interrupt+0x37/0x60 __ipipe_sync_stage+0x350/0x355 smp_apic_timer_interrupt+0x0/0x60 __xirq_end+0x0/0x85 smp_apic_timer_interrupt+0x0/0x60 __ipipe_handle_irq+0x91/0x250 default_idle+0x0/0x40 common_interrupt+0x61/0x7d <EOI> default_idle+0x29/0x40 cpu_idle+0x8b/0x120 start_kernel+0x2ba/0x350 _sinittext+0x120/0x130 Code: 48 8b 11 48 89 d0 48 c1 e8 16 48 85 c0 75 1b 48 8b 51 08 48
RIP profile_pc+0x46/0x80
RSP <ffffffff80664da0>
CR2: 0000000040090fb8
---[ end trace ccd2184e479f15c8 ]--- Kernel panic - not syncing: Aiee, killing interrupt handler!
Another one is similar, with following differencies:
----------------------------------------------------------------------
<IRQ> scheduler_tick+0xf8/0x140 ... /* same part as before */ smp_apic_timer_interrupt+0x0/0x60 ipipe_suspend_domain+0xb2/0xf0 __ipipe_walk_pipeline+0xee/0x150 __ipipe_handle_irq+0x81/0x250 common_interrupt+0x61/0x7d
<EOI>
Code: 0f 0b eb fe 66 66 66 2e 0f 1f 84 00 00 00 00 00 41 57 41 56
RIP run_posix_cpu_timers+0x810/0x280
...
Quoted 4 lines · Petr Cervenka
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 ofkernel/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,
arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +1 -6
@@ -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 */ }
Signature · 1 line
Philippe.
Quoted 3 lines
Quoted 3 lines
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/...
Quoted 1 line
Quoted 1 line
If you have any questions, i'll try to answer them. Any help is
welcome.
Quoted 2 lines
It is an I-pipe issue, probably. We have to somewhat forge the register
frame
Quoted 1 line
passed to the Linux tick handler, since we may delay that call. Some
register
Quoted 1 line
values the profiling code attempts to dereference to find the preempted
code may
Quoted 3 lines
be wrong in our case.
Could you 1) send back a disassembly of the
profile_tickroutine in your
kernel
Quoted 1 line
image, then apply the following patch to check whether it improves the
situation
Quoted 2 lines
as well? TIA,
ad 1) I would like to, but i don't know how to do it. If you have a simple guide or a link, I would be grateful. ad 2) I will apply the patch. But it will take days (or a week) before I could tell, if it helped or not.
Petr
Quoted 19 lines · Philippe Gerum
Quoted 4 lines · Petr Cervenka
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 ofkernel/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_tickroutine in your kernel image, then apply the following patch to check whether it improves the situation as well? TIA,arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +0
-0@@ -933,12 +933,7 @@ tick_regs->eip = regs.eip;
arch/x86/kernel/ipipe.c line 937
Quoted 10 lines
arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +1
-6tick_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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 27 lines · Jan Kiszka
Quoted 26 lines · Philippe Gerum
Quoted 4 lines · Petr Cervenka
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 ofkernel/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_tickroutine in your kernel image, then apply the following patch to check whether it improves the situation as well? TIA,arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +0
-6@@ -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;
Quoted 8 lines
arch/x86/kernel/ipipe.c line 937
Quoted 2 lines
arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +1
-0+ *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.
Signature · 1 line
Gilles.
Quoted 47 lines · Gilles Chanteperdrix
Quoted 37 lines · Jan Kiszka
Quoted 36 lines · Philippe Gerum
Quoted 7 lines · Petr Cervenka
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 ofkernel/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_tickroutine 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.c2008-07-07
17:55:36.000000000 +0200arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +0
-6@@ -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;Quoted 8 lines
arch/x86/kernel/ipipe.c line 937
Quoted 2 lines
arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +1
-0+ *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.
Quoted 7 lines
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_exitcan 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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 36 lines · Jan Kiszka
Quoted 35 lines · Gilles Chanteperdrix
Quoted 34 lines · Jan Kiszka
Quoted 33 lines · Philippe Gerum
Quoted 7 lines · Petr Cervenka
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 ofkernel/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_tickroutine 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.c2008-07-07
17:55:36.000000000 +0200arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +0
-3@@ -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;
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/x86/kernel/ipipe.c line 937
Quoted 5 lines
arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +1
-3- 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
Quoted 10 lines
Quoted 10 lines
Quoted 3 lines
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_exitcan 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.
Quoted 11 lines
Quoted 1 line
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 -dSlinux-.../arch/x86/kernel/time_64.o.
To your questions:
we have only user space tasks, but we use rtdm driver (with ioctl, no tasks).
The processor is Athlon X2, 64-bit distribution (Kubuntu ?7.10?), x86_64 SMP PREEMPT,
Kernel 2.6.24, Xenomai 2.4.1, adeos-ipipe-2.6.24-x86-2.0-03
I could send you my kernel config file if you want.
I will try to learn the method of oopses catching via serial cable attached second box. But I don't know if it will be possible to setup such experiment for time long enough to reproduce the error.
The following disassembly is from different machine than the one which has the kernel panics. I use it for developing and testing but it should have the same HW and kernel configuration. I can't totally sure, that the disassembly is correct, but i hope so. I junst can't recognise it. Could you explain me what does "profile_pc+0x46/0x80"? I assume the first number is the current RIP address (relative to routine start), so 0x256 in this case. But what does mean the second number?
0000000000000210 <profile_pc>:
210: 48 83 ec 18 sub $0x18,%rsp 214: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 219: 48 89 6c 24 10 mov %rbp,0x10(%rsp) 21e: 48 89 fb mov %rdi,%rbx 221: f6 87 88 00 00 00 03 testb $0x3,0x88(%rdi) 228: 48 8b af 80 00 00 00 mov 0x80(%rdi),%rbp 22f: 74 12 je 243 <profile_pc+0x33> 231: 48 89 e8 mov %rbp,%rax 234: 48 8b 5c 24 08 mov 0x8(%rsp),%rbx 239: 48 8b 6c 24 10 mov 0x10(%rsp),%rbp 23e: 48 83 c4 18 add $0x18,%rsp 242: c3 retq 243: 48 89 ef mov %rbp,%rdi 246: e8 00 00 00 00 callq 24b <profile_pc+0x3b> 24b: 85 c0 test %eax,%eax 24d: 74 e2 je 231 <profile_pc+0x21> 24f: 48 8b 8b 98 00 00 00 mov 0x98(%rbx),%rcx 256: 48 8b 11 mov (%rcx),%rdx 259: 48 89 d0 mov %rdx,%rax 25c: 48 c1 e8 16 shr $0x16,%rax 260: 48 85 c0 test %rax,%rax 263: 75 1b jne 280 <profile_pc+0x70> 265: 48 8b 51 08 mov 0x8(%rcx),%rdx 269: 48 89 d0 mov %rdx,%rax 26c: 48 c1 e8 16 shr $0x16,%rax 270: 48 85 c0 test %rax,%rax 273: 48 0f 45 ea cmovne %rdx,%rbp 277: eb b8 jmp 231 <profile_pc+0x21> 279: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 280: 48 89 d5 mov %rdx,%rbp 283: eb ac jmp 231 <profile_pc+0x21> 285: 66 66 2e 0f 1f 84 00 nopw %cs:0x0(%rax,%rax,1)
28c: 00 00 00 00
Quoted 65 lines · Petr Cervenka
Quoted 35 lines · Jan Kiszka
Quoted 34 lines · Gilles Chanteperdrix
Quoted 33 lines · Jan Kiszka
Quoted 32 lines · Philippe Gerum
Quoted 7 lines · Petr Cervenka
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 ofkernel/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_tickroutine 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.c2008-07-07
17:55:36.000000000 +0200arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +0
-2@@ -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;Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/x86/kernel/ipipe.c line 937
Quoted 6 lines
arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +1
-4- 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 aroundon
Quoted 9 lines
Quoted 9 lines
Quoted 3 lines
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_exitcan 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 isimpossible.
Quoted 9 lines
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 -dSlinux-.../arch/x86/kernel/time_64.o.
Quoted 8 lines
To your questions:
we have only user space tasks, but we use rtdm driver (with ioctl, no tasks).
The processor is Athlon X2, 64-bit distribution (Kubuntu ?7.10?),x86_64SMP PREEMPT,
Kernel 2.6.24, Xenomai 2.4.1, adeos-ipipe-2.6.24-x86-2.0-03
I could send you my kernel config file if you want.
I will try to learn the method of oopses catching via serial cable attached second box. But I don't know if it will be possible to setup such experiment for time long enough to reproduce the error.The following disassembly is from different machine than the one which has the kernel panics. I use it for developing and testing but it should have the same HW and kernel configuration. I can't totally sure, that the disassembly is correct, but i hope so. I junst can't recognise it. Could you explain me what does "
profile_pc+0x46/0x80"? I assume the first number is the current RIP address (relative to routine start), so0x256in this case. But what does mean the second number?
Size of the routine.
Quoted 18 lines
0000000000000210 <
profile_pc>:210: 48 83 ec 18 sub $0x18,%rsp 214: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 219: 48 89 6c 24 10 mov %rbp,0x10(%rsp) 21e: 48 89 fb mov %rdi,%rbx 221: f6 87 88 00 00 00 03 testb $0x3,0x88(%rdi) 228: 48 8b af 80 00 00 00 mov 0x80(%rdi),%rbp 22f: 74 12 je 243 <profile_pc+0x33> 231: 48 89 e8 mov %rbp,%rax 234: 48 8b 5c 24 08 mov 0x8(%rsp),%rbx 239: 48 8b 6c 24 10 mov 0x10(%rsp),%rbp 23e: 48 83 c4 18 add $0x18,%rsp 242: c3 retq 243: 48 89 ef mov %rbp,%rdi 246: e8 00 00 00 00 callq 24b <profile_pc+0x3b> 24b: 85 c0 test %eax,%eax 24d: 74 e2 je 231 <profile_pc+0x21>
Quoted 2 lines
24f: 48 8b 8b 98 00 00 00 mov 0x98(%rbx),%rcx
256: 48 8b 11 mov (%rcx),%rdx
We are dereferencing invalid stack memory, using the stack pointer value of the preempted context.
What could help is to have the registers dump which should appear in the oops message, and specifically the %rcx value.
Quoted 17 lines
259: 48 89 d0 mov %rdx,%rax 25c: 48 c1 e8 16 shr $0x16,%rax 260: 48 85 c0 test %rax,%rax 263: 75 1b jne 280 <profile_pc+0x70> 265: 48 8b 51 08 mov 0x8(%rcx),%rdx 269: 48 89 d0 mov %rdx,%rax 26c: 48 c1 e8 16 shr $0x16,%rax 270: 48 85 c0 test %rax,%rax 273: 48 0f 45 ea cmovne %rdx,%rbp 277: eb b8 jmp 231 <profile_pc+0x21> 279: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 280: 48 89 d5 mov %rdx,%rbp 283: eb ac jmp 231 <profile_pc+0x21> 285: 66 66 2e 0f 1f 84 00 nopw %cs:0x0(%rax,%rax,1)28c: 00 00 00 00
Signature · 1 line
Philippe.
Quoted 10 lines · Philippe Gerum
Quoted 9 lines · Petr Cervenka
Quoted 8 lines · Jan Kiszka
Quoted 7 lines · Gilles Chanteperdrix
Quoted 6 lines · Jan Kiszka
Quoted 5 lines · Philippe Gerum
Quoted 4 lines · Petr Cervenka
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
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
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_tickroutine 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.c2008-07-07
17:55:36.000000000 +0200arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +0
-1@@ -933,12 +933,7 @@ tick_regs->eip = regs.eip; tick_regs->ebp = regs.ebp;#else /* !CONFIG_X86_32 */ - tick_regs->ss = regs->ss;
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/x86/kernel/ipipe.c line 937
Quoted 7 lines
arch/x86/kernel/ipipe.c renamed from arch/x86/kernel/ipipe.c~ +1
-5- 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
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
first dump we crash in
profile_pc, and there the kernel pokes aroundon
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
would have to vanish upon execution of another interrupt handler
before
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
the tick handler. However, I believe that only
do_exitcan kill a
task,
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
and I am not sure if it can be called from an interrupt handler. As
for
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
Quoted 1 line
the stack being swapped out, it is kmalloced memory, so, it is
impossible.
Quoted 5 lines
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,
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
but also, as Philippe already requested, a disassembly of the involved function - in case it remain
profile_pc: objdump -dSlinux-.../arch/x86/kernel/time_64.o.To your questions:
we have only user space tasks, but we use rtdm driver (with ioctl, no
tasks).
Quoted 1 line
Quoted 1 line
The processor is Athlon X2, 64-bit distribution (Kubuntu ?7.10?),
x86_64 SMP PREEMPT,
Quoted 3 lines
Quoted 3 lines
Kernel 2.6.24, Xenomai 2.4.1, adeos-ipipe-2.6.24-x86-2.0-03 I could send you my kernel config file if you want.
I will try to learn the method of oopses catching via serial cable
attached second box. But I don't know if it will be possible to setup such experiment for time long enough to reproduce the error.
Quoted 2 lines
Quoted 2 lines
The following disassembly is from different machine than the one which
has the kernel panics. I use it for developing and testing but it should have the same HW and kernel configuration. I can't totally sure, that the disassembly is correct, but i hope so. I junst can't recognise it. Could you explain me what does "profile_pc+0x46/0x80"? I assume the first number is the current RIP address (relative to routine start), so 0x256 in this case. But what does mean the second number?
Quoted 24 lines
Size of the routine.
Quoted 18 lines
0000000000000210 <
profile_pc>:210: 48 83 ec 18 sub $0x18,%rsp 214: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 219: 48 89 6c 24 10 mov %rbp,0x10(%rsp) 21e: 48 89 fb mov %rdi,%rbx 221: f6 87 88 00 00 00 03 testb $0x3,0x88(%rdi) 228: 48 8b af 80 00 00 00 mov 0x80(%rdi),%rbp 22f: 74 12 je 243 <profile_pc+0x33> 231: 48 89 e8 mov %rbp,%rax 234: 48 8b 5c 24 08 mov 0x8(%rsp),%rbx 239: 48 8b 6c 24 10 mov 0x10(%rsp),%rbp 23e: 48 83 c4 18 add $0x18,%rsp 242: c3 retq 243: 48 89 ef mov %rbp,%rdi 246: e8 00 00 00 00 callq 24b <profile_pc+0x3b> 24b: 85 c0 test %eax,%eax 24d: 74 e2 je 231 <profile_pc+0x21>Quoted 2 lines
24f: 48 8b 8b 98 00 00 00 mov 0x98(%rbx),%rcx
256: 48 8b 11 mov (%rcx),%rdx
Quoted 1 line
We are dereferencing invalid stack memory, using the stack pointer value
of the
Quoted 3 lines
preempted context.
What could help is to have the registers dump which should appear in the
oops
Quoted 1 line
message, and specifically the %rcx value.
I tried to setup the serial line console but with only partial success.
I used this guide: http://www.av8n.com/computer/htm/kernel-lockup.htm (not the watchdog part)
Now I am able through gtkterm to login to the 1. (logged) machine from the 2. (logging) machine. But when I try to use: echo "Hi there." > /dev/console, i see the text only on the actual session (tty0) and not on the connected 2. machine (maybe the gtkterm could be not the right program for it). When I use directly: echo "Hi there." > /dev/ttyS0, it freezes and I have to press Ctrl+C to continue (with: Interrupted signal call error).
In the dmesg output of the first machine, there is line: console [ttyS0] enabled. the console ttyS0, the getty on ttyS0 and the gtkterm use the same 115200 speed.
What have I done wrong?
Petr
I was able to capture the kernel panic through the serial line. This time, it took less time than I expected. Petr
[ 2009.702873] Unable to handle kernel paging request at 0000000040090ff8 RIP: [ 2009.708187] [<ffffffff802101a6>] profile_pc+0x46/0x80 [ 2009.716892] PGD 116fd067 PUD 116b5067 PMD 3d93d067 PTE 0 [ 2009.722998] Oops: 0000 [1] PREEMPT SMP [ 2009.727400] CPU 0 [ 2009.729800] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat usb_storage libusual rt_e1000 rt_r8169 rtpacket rtnet ppdev pci171x_rtdm(P) container ac video output sbs sbshc dock battery parport_pc lp parport psmouse serio_raw pcspkr k8temp i2c_nforce2 i2c_core button af_packet ipv6 evdev ext3 jbd mbcache sg sd_mod ide_cd cdrom sata_nv floppy forcedeth ata_generic libata scsi_mod amd74xx ehci_hcd ohci_hcd ide_core usbcore fan fuse [ 2009.774477] Pid: 0, comm: swapper Tainted: P 2.6.24-adeos #1 [ 2009.781682] RIP: 0010:[<ffffffff802101a6>] [<ffffffff802101a6>] profile_pc+0x46/0x80 [ 2009.790682] RSP: 0018:ffffffff80664da0 EFLAGS: 00010202 [ 2009.796869] RAX: 0000000000000001 RBX: ffff8100010087a0 RCX: 0000000040090ff8 [ 2009.804953] RDX: ffff8100809b4000 RSI: 0000000000000906 RDI: ffffffff8048c6c8 [ 2009.813179] RBP: ffffffff8048c6c8 R08: 0000000000000004 R09: 0000000000000010 [ 2009.821383] R10: 0000000000000005 R11: ffffffff80258ee0 R12: ffff81000100a5c0 [ 2009.829667] R13: 000001d1bcf596b9 R14: 0000000000000000 R15: 0000000000000001 [ 2009.837867] FS: 0000000040091950(0000) GS:ffffffff805d6000(0000) knlGS:0000000000000000 [ 2009.847177] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b [ 2009.853762] CR2: 0000000040090ff8 CR3: 0000000014cfd000 CR4: 00000000000006e0 [ 2009.862084] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2009.870373] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 2009.878572] Process swapper (pid: 0, threadinfo ffffffff80602000, task ffffffff805a03a0) [ 2009.887786] Stack: 000001d1bcf596b9 ffff8100010087a0 0000000000000001 ffffffff8023fd3e [ 2009.897090] 000001d1bcf596b9 ffff81000100a6c0 ffff8100010087a0 ffffffff8025e8a5 [ 2009.905760] ffff81000100a618 ffff81000100a6c0 ffff81000100a618 000001d1bcf58f16 [ 2009.914068] Call Trace: [ 2009.917071] <IRQ> [<ffffffff8023fd3e>] profile_tick+0x5e/0xa0 [ 2009.923847] [<ffffffff8025e8a5>] tick_sched_timer+0x85/0x170 [ 2009.930374] [<ffffffff8025900f>] hrtimer_interrupt+0x12f/0x1e0 [ 2009.937150] [<ffffffff80220857>] smp_apic_timer_interrupt+0x37/0x60 [ 2009.944454] [<ffffffff802777e0>] __ipipe_sync_stage+0x350/0x355 [ 2009.951351] [<ffffffff80220820>] smp_apic_timer_interrupt+0x0/0x60 [ 2009.958555] [<ffffffff802777e5>] __xirq_end+0x0/0x85 [ 2009.964349] [<ffffffff80220820>] smp_apic_timer_interrupt+0x0/0x60 [ 2009.971558] [<ffffffff80226b01>] __ipipe_handle_irq+0x91/0x250 [ 2009.978457] [<ffffffff8020af50>] default_idle+0x0/0x40 [ 2009.984437] [<ffffffff8020c9f1>] common_interrupt+0x61/0x7d [ 2009.990940] <EOI> [<ffffffff8020af79>] default_idle+0x29/0x40 [ 2009.997762] [<ffffffff8020b01b>] cpu_idle+0x8b/0x120 [ 2010.003541] [<ffffffff8060cbba>] start_kernel+0x2ba/0x350 [ 2010.009741] [<ffffffff8060c120>] _sinittext+0x120/0x130 [ 2010.015821] [ 2010.017549] [ 2010.017556] Code: 48 8b 11 48 89 d0 48 c1 e8 16 48 85 c0 75 1b 48 8b 51 08 48 [ 2010.028006] RIP [<ffffffff802101a6>] profile_pc+0x46/0x80 [ 2010.034335] RSP <ffffffff80664da0> [ 2010.038334] CR2: 0000000040090ff8 [ 2010.042166] ---[ end trace 95174c527ade95f0 ]--- [ 2010.047468] Kernel panic - not syncing: Aiee, killing interrupt handler!
Quoted 36 lines
Quoted 36 lines
0000000000000210 <
profile_pc>:210: 48 83 ec 18 sub $0x18,%rsp 214: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 219: 48 89 6c 24 10 mov %rbp,0x10(%rsp) 21e: 48 89 fb mov %rdi,%rbx 221: f6 87 88 00 00 00 03 testb $0x3,0x88(%rdi) 228: 48 8b af 80 00 00 00 mov 0x80(%rdi),%rbp 22f: 74 12 je 243 <profile_pc+0x33> 231: 48 89 e8 mov %rbp,%rax 234: 48 8b 5c 24 08 mov 0x8(%rsp),%rbx 239: 48 8b 6c 24 10 mov 0x10(%rsp),%rbp 23e: 48 83 c4 18 add $0x18,%rsp 242: c3 retq 243: 48 89 ef mov %rbp,%rdi 246: e8 00 00 00 00 callq 24b <profile_pc+0x3b> 24b: 85 c0 test %eax,%eax 24d: 74 e2 je 231 <profile_pc+0x21> 24f: 48 8b 8b 98 00 00 00 mov 0x98(%rbx),%rcx 256: 48 8b 11 mov (%rcx),%rdx 259: 48 89 d0 mov %rdx,%rax 25c: 48 c1 e8 16 shr $0x16,%rax 260: 48 85 c0 test %rax,%rax 263: 75 1b jne 280 <profile_pc+0x70> 265: 48 8b 51 08 mov 0x8(%rcx),%rdx 269: 48 89 d0 mov %rdx,%rax 26c: 48 c1 e8 16 shr $0x16,%rax 270: 48 85 c0 test %rax,%rax 273: 48 0f 45 ea cmovne %rdx,%rbp 277: eb b8 jmp 231 <profile_pc+0x21> 279: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 280: 48 89 d5 mov %rdx,%rbp 283: eb ac jmp 231 <profile_pc+0x21> 285: 66 66 2e 0f 1f 84 00 nopw %cs:0x0(%rax,%rax,1)28c: 00 00 00 00
I captured also the second type of kernel panic. This one seems to happen during "advanced" configuration of out system. This means lot of work in a low priority (5) xenomai task (WORK_TASK_2056) for a short time. Another question is, what does mean "(P)" after the name of our rtdm module (pci171x_rtdm(P))?
[ 7815.694296] ------------[ cut here ]------------ [ 7815.699111] kernel BUG at kernel/posix-cpu-timers.c:1295! [ 7815.704715] invalid opcode: 0000 [1] PREEMPT SMP [ 7815.709672] CPU 0 [ 7815.711777] Modules linked in: rt_e1000 rt_r8169 rtpacket rtnet ppdev pci171x_rtdm(P) container ac video output sbs sbshc dock battery parport_pc lp parport psmouse serio_raw pcspkr k8temp i2c_nforce2 button i2c_core af_packet ipv6 evdev ext3 jbd mbcache sg sd_mod ide_cd cdrom sata_nv floppy ata_generic libata ohci_hcd forcedeth ehci_hcd scsi_mod amd74xx ide_core usbcore fan fuse [ 7815.747844] Pid: 6481, comm: WORK_TASK_2056 Tainted: P 2.6.24-adeos #1 [ 7815.755321] RIP: 0010:[<ffffffff80256e20>] [<ffffffff80256e20>] run_posix_cpu_timers+0x810/0x820 [ 7815.764629] RSP: 0000:ffffffff80664d70 EFLAGS: 00010246 [ 7815.770122] RAX: ffff81000100a7c0 RBX: ffff81003e082780 RCX: ffffffff805a03a0 [ 7815.777573] RDX: 0000000000000000 RSI: ffff81003e082780 RDI: ffff81003e082780 [ 7815.785080] RBP: ffff8100010087a0 R08: 0000000000000004 R09: 0000000000000010 [ 7815.792566] R10: 0000000000000005 R11: ffffffff80258ee0 R12: ffff81000100a5c0 [ 7815.800001] R13: 00000719439890f1 R14: 0000000000000000 R15: ffffffff80664d90 [ 7815.807436] FS: 0000000040112950(0063) GS:ffffffff805d6000(0000) knlGS:0000000000000000 [ 7815.815909] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7815.821915] CR2: 00002b83d55aec80 CR3: 000000003dff8000 CR4: 00000000000006e0 [ 7815.829357] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 7815.836786] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 7815.844238] Process WORK_TASK_2056 (pid: 6481, threadinfo ffff810013f78000, task ffff81003e082780) [ 7815.853584] Stack: ffff810001013180 00000718f7bcb1dd ffffffff80664db0 ffffffff80238af8 [ 7815.862131] ffffffff80664d90 ffffffff80664d90 00000719439890f1 ffff81000100a6c0 [ 7815.869974] ffff8100010087a0 ffff81000100a5c0 00000719439890f1 0000000000000000 [ 7815.877667] Call Trace: [ 7815.880441] <IRQ> [<ffffffff80238af8>] scheduler_tick+0xf8/0x140 [ 7815.886908] [<ffffffff8025e89b>] tick_sched_timer+0x7b/0x170 [ 7815.892929] [<ffffffff8025900f>] hrtimer_interrupt+0x12f/0x1e0 [ 7815.899137] [<ffffffff80220857>] smp_apic_timer_interrupt+0x37/0x60 [ 7815.905752] [<ffffffff8020c9f1>] common_interrupt+0x61/0x7d [ 7815.911779] [<ffffffff802777e0>] __ipipe_sync_stage+0x350/0x355 [ 7815.918085] [<ffffffff80220820>] smp_apic_timer_interrupt+0x0/0x60 [ 7815.924655] [<ffffffff802777e5>] __xirq_end+0x0/0x85 [ 7815.929964] [<ffffffff80220820>] smp_apic_timer_interrupt+0x0/0x60 [ 7815.936587] [<ffffffff80226b01>] __ipipe_handle_irq+0x91/0x250 [ 7815.942774] [<ffffffff8020c9f1>] common_interrupt+0x61/0x7d [ 7815.948673] <EOI> [ 7815.950909] [ 7815.950909] Code: 0f 0b eb fe 66 66 66 2e 0f 1f 84 00 00 00 00 00 41 57 41 56 [ 7815.960491] RIP [<ffffffff80256e20>] run_posix_cpu_timers+0x810/0x820 [ 7815.967284] RSP <ffffffff80664d70> [ 7815.970982] ---[ end trace d192885d9858c4b2 ]--- [ 7815.975820] Kernel panic - not syncing: Aiee, killing interrupt handler!
Quoted 2 lines · Petr Cervenka
I captured also the second type of kernel panic. This one seems to happen during "advanced" configuration of out system. This means lot of work in a low priority (5) xenomai task (
WORK_TASK_2056) for a short time. Another question is, what does mean "(P)" after the name of our rtdm module (pci171x_rtdm(P))?
That it either does not comply to the GPL or that the author forgot to announce its compliance via MODULE_LICENSE().
Quoted 34 lines
[ 7815.694296] ------------[ cut here ]------------ [ 7815.699111] kernel BUG at kernel/posix-cpu-timers.c:1295! [ 7815.704715] invalid opcode: 0000 [1] PREEMPT SMP [ 7815.709672] CPU 0 [ 7815.711777] Modules linked in: rt_e1000 rt_r8169 rtpacket rtnet ppdev pci171x_rtdm(P) container ac video output sbs sbshc dock battery parport_pc lp parport psmouse serio_raw pcspkr k8temp i2c_nforce2 button i2c_core af_packet ipv6 evdev ext3 jbd mbcache sg sd_mod ide_cd cdrom sata_nv floppy ata_generic libata ohci_hcd forcedeth ehci_hcd scsi_mod amd74xx ide_core usbcore fan fuse [ 7815.747844] Pid: 6481, comm: WORK_TASK_2056 Tainted: P 2.6.24-adeos #1 [ 7815.755321] RIP: 0010:[<ffffffff80256e20>] [<ffffffff80256e20>] run_posix_cpu_timers+0x810/0x820 [ 7815.764629] RSP: 0000:ffffffff80664d70 EFLAGS: 00010246 [ 7815.770122] RAX: ffff81000100a7c0 RBX: ffff81003e082780 RCX: ffffffff805a03a0 [ 7815.777573] RDX: 0000000000000000 RSI: ffff81003e082780 RDI: ffff81003e082780 [ 7815.785080] RBP: ffff8100010087a0 R08: 0000000000000004 R09: 0000000000000010 [ 7815.792566] R10: 0000000000000005 R11: ffffffff80258ee0 R12: ffff81000100a5c0 [ 7815.800001] R13: 00000719439890f1 R14: 0000000000000000 R15: ffffffff80664d90 [ 7815.807436] FS: 0000000040112950(0063) GS:ffffffff805d6000(0000) knlGS:0000000000000000 [ 7815.815909] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7815.821915] CR2: 00002b83d55aec80 CR3: 000000003dff8000 CR4: 00000000000006e0 [ 7815.829357] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 7815.836786] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 7815.844238] Process WORK_TASK_2056 (pid: 6481, threadinfo ffff810013f78000, task ffff81003e082780) [ 7815.853584] Stack: ffff810001013180 00000718f7bcb1dd ffffffff80664db0 ffffffff80238af8 [ 7815.862131] ffffffff80664d90 ffffffff80664d90 00000719439890f1 ffff81000100a6c0 [ 7815.869974] ffff8100010087a0 ffff81000100a5c0 00000719439890f1 0000000000000000 [ 7815.877667] Call Trace: [ 7815.880441] <IRQ> [<ffffffff80238af8>] scheduler_tick+0xf8/0x140 [ 7815.886908] [<ffffffff8025e89b>] tick_sched_timer+0x7b/0x170 [ 7815.892929] [<ffffffff8025900f>] hrtimer_interrupt+0x12f/0x1e0 [ 7815.899137] [<ffffffff80220857>] smp_apic_timer_interrupt+0x37/0x60 [ 7815.905752] [<ffffffff8020c9f1>] common_interrupt+0x61/0x7d [ 7815.911779] [<ffffffff802777e0>] __ipipe_sync_stage+0x350/0x355 [ 7815.918085] [<ffffffff80220820>] smp_apic_timer_interrupt+0x0/0x60 [ 7815.924655] [<ffffffff802777e5>] __xirq_end+0x0/0x85 [ 7815.929964] [<ffffffff80220820>] smp_apic_timer_interrupt+0x0/0x60 [ 7815.936587] [<ffffffff80226b01>] __ipipe_handle_irq+0x91/0x250
Quoted 8 lines
[ 7815.942774] [<ffffffff8020c9f1>] common_interrupt+0x61/0x7d [ 7815.948673] <EOI> [ 7815.950909] [ 7815.950909] Code: 0f 0b eb fe 66 66 66 2e 0f 1f 84 00 00 00 00 00 41 57 41 56 [ 7815.960491] RIP [<ffffffff80256e20>] run_posix_cpu_timers+0x810/0x820 [ 7815.967284] RSP <ffffffff80664d70> [ 7815.970982] ---[ end trace d192885d9858c4b2 ]--- [ 7815.975820] Kernel panic - not syncing: Aiee, killing interrupt handler!
That's now a totally different spot, and it makes me wonder if can reproduce all this troubles with vanilla Xenomai and without your driver being loaded...
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 2 lines · Jan Kizska
Quoted 1 line · Petr Cervenka
I captured also the second type of kernel panic. This one seems to
happen during "advanced" configuration of out system. This means lot of work in a low priority (5) xenomai task (WORK_TASK_2056) for a short time.
Quoted 1 line
Quoted 1 line
Another question is, what does mean "(P)" after the name of our rtdm
module (pci171x_rtdm(P))?
Quoted 10 lines
That it either does not comply to the GPL or that the author forgot to announce its compliance via
MODULE_LICENSE().Quoted 6 lines
[ 7815.694296] ------------[ cut here ]------------ [ 7815.699111] kernel BUG at kernel/posix-cpu-timers.c:1295! [ 7815.704715] invalid opcode: 0000 [1] PREEMPT SMP [ 7815.709672] CPU 0 [ 7815.711777] Modules linked in: rt_e1000 rt_r8169 rtpacket rtnet
ppdev pci171x_rtdm(P) container ac video output sbs sbshc dock battery parport_pc lp parport psmouse serio_raw pcspkr k8temp i2c_nforce2 button i2c_core af_packet ipv6 evdev ext3 jbd mbcache sg sd_mod ide_cd cdrom sata_nv floppy ata_generic libata ohci_hcd forcedeth ehci_hcd scsi_mod amd74xx ide_core usbcore fan fuse
Quoted 1 line
Quoted 1 line
[ 7815.747844] Pid: 6481, comm: WORK_TASK_2056 Tainted: P
2.6.24-adeos #1
Quoted 1 line
Quoted 1 line
[ 7815.755321] RIP: 0010:[<ffffffff80256e20>] [<ffffffff80256e20>]
run_posix_cpu_timers+0x810/0x820 >> [ 7815.764629] RSP: 0000:ffffffff80664d70 EFLAGS: 00010246 >> [ 7815.770122] RAX: ffff81000100a7c0 RBX: ffff81003e082780 RCX:
ffffffff805a03a0
Quoted 1 line
Quoted 1 line
[ 7815.777573] RDX: 0000000000000000 RSI: ffff81003e082780 RDI:
ffff81003e082780
Quoted 1 line
Quoted 1 line
[ 7815.785080] RBP: ffff8100010087a0 R08: 0000000000000004 R09:
0000000000000010
Quoted 1 line
Quoted 1 line
[ 7815.792566] R10: 0000000000000005 R11: ffffffff80258ee0 R12:
ffff81000100a5c0
Quoted 1 line
Quoted 1 line
[ 7815.800001] R13: 00000719439890f1 R14: 0000000000000000 R15:
ffffffff80664d90
Quoted 1 line
Quoted 1 line
[ 7815.807436] FS: 0000000040112950(0063) GS:ffffffff805d6000(0000)
knlGS:0000000000000000
Quoted 2 lines
Quoted 2 lines
[ 7815.815909] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7815.821915] CR2: 00002b83d55aec80 CR3: 000000003dff8000 CR4:
00000000000006e0
Quoted 1 line
Quoted 1 line
[ 7815.829357] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
Quoted 1 line
Quoted 1 line
[ 7815.836786] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
Quoted 1 line
Quoted 1 line
[ 7815.844238] Process WORK_TASK_2056 (pid: 6481, threadinfo
ffff810013f78000, task ffff81003e082780)
Quoted 1 line
Quoted 1 line
[ 7815.853584] Stack: ffff810001013180 00000718f7bcb1dd
ffffffff80664db0 ffffffff80238af8
Quoted 1 line
Quoted 1 line
[ 7815.862131] ffffffff80664d90 ffffffff80664d90 00000719439890f1
ffff81000100a6c0
Quoted 1 line
Quoted 1 line
[ 7815.869974] ffff8100010087a0 ffff81000100a5c0 00000719439890f1
0000000000000000
Quoted 7 lines
Quoted 7 lines
[ 7815.877667] Call Trace: [ 7815.880441] <IRQ> [<ffffffff80238af8>] scheduler_tick+0xf8/0x140 [ 7815.886908] [<ffffffff8025e89b>] tick_sched_timer+0x7b/0x170 [ 7815.892929] [<ffffffff8025900f>] hrtimer_interrupt+0x12f/0x1e0 [ 7815.899137] [<ffffffff80220857>] smp_apic_timer_interrupt+0x37/0x60 [ 7815.905752] [<ffffffff8020c9f1>] common_interrupt+0x61/0x7d [ 7815.911779] [<ffffffff802777e0>] __ipipe_sync_stage+0x350/0x355
Quoted 8 lines
Quoted 8 lines
[ 7815.918085] [<ffffffff80220820>] smp_apic_timer_interrupt+0x0/0x60 [ 7815.924655] [<ffffffff802777e5>] __xirq_end+0x0/0x85 [ 7815.929964] [<ffffffff80220820>] smp_apic_timer_interrupt+0x0/0x60 [ 7815.936587] [<ffffffff80226b01>] __ipipe_handle_irq+0x91/0x250 [ 7815.942774] [<ffffffff8020c9f1>] common_interrupt+0x61/0x7d [ 7815.948673] <EOI> [ 7815.950909] [ 7815.950909] Code: 0f 0b eb fe 66 66 66 2e 0f 1f 84 00 00 00 00 00 41
57 41 56
Quoted 1 line
Quoted 1 line
[ 7815.960491] RIP [<ffffffff80256e20>]
run_posix_cpu_timers+0x810/0x820
Quoted 3 lines
Quoted 3 lines
[ 7815.967284] RSP <ffffffff80664d70> [ 7815.970982] ---[ end trace d192885d9858c4b2 ]--- [ 7815.975820] Kernel panic - not syncing: Aiee, killing interrupt
handler!
Quoted 5 lines
That's now a totally different spot, and it makes me wonder if can reproduce all this troubles with vanilla Xenomai and without your driver being loaded...
We measure data from our unit connected through rtnet or with a PCI card. It's independent if we use one way or another, these kernel panics appear in both setups. So rtnet and our module are not involved. But it does depend on the measuring frequency and the amount of measured data in every cycle.
Petr
Quoted 73 lines · Petr Cervenka
Quoted 2 lines · Jan Kizska
Quoted 1 line · Petr Cervenka
I captured also the second type of kernel panic. This one seems to
happen during "advanced" configuration of out system. This means lot of work in a low priority (5) xenomai task (
WORK_TASK_2056) for a short time.Quoted 1 line
Quoted 1 line
Another question is, what does mean "(P)" after the name of our rtdm
module (
pci171x_rtdm(P))?Quoted 8 lines
That it either does not comply to the GPL or that the author forgot to announce its compliance via
MODULE_LICENSE().Quoted 5 lines
[ 7815.694296] ------------[ cut here ]------------ [ 7815.699111] kernel BUG at kernel/posix-cpu-timers.c:1295! [ 7815.704715] invalid opcode: 0000 [1] PREEMPT SMP [ 7815.709672] CPU 0 [ 7815.711777] Modules linked in: rt_e1000 rt_r8169 rtpacket rtnetppdev
pci171x_rtdm(P)container ac video output sbs sbshc dock batteryparport_pclp parport psmouseserio_rawpcspkr k8tempi2c_nforce2buttoni2c_coreaf_packetipv6 evdev ext3 jbd mbcache sgsd_modide_cdcdromsata_nvfloppyata_genericlibataohci_hcdforcedethehci_hcdscsi_modamd74xxide_coreusbcore fan fuseQuoted 1 line
Quoted 1 line
[ 7815.747844] Pid: 6481, comm: WORK_TASK_2056 Tainted: P2.6.24-adeos #1
Quoted 1 line
Quoted 1 line
[ 7815.755321] RIP: 0010:[<ffffffff80256e20>] [<ffffffff80256e20>]run_posix_cpu_timers+0x810/0x820 >> [ 7815.764629] RSP: 0000:ffffffff80664d70 EFLAGS: 00010246 >> [ 7815.770122] RAX: ffff81000100a7c0 RBX: ffff81003e082780 RCX:
ffffffff805a03a0Quoted 1 line
Quoted 1 line
[ 7815.777573] RDX: 0000000000000000 RSI: ffff81003e082780 RDI:
ffff81003e082780Quoted 1 line
Quoted 1 line
[ 7815.785080] RBP: ffff8100010087a0 R08: 0000000000000004 R09:0000000000000010
Quoted 1 line
Quoted 1 line
[ 7815.792566] R10: 0000000000000005 R11: ffffffff80258ee0 R12:
ffff81000100a5c0Quoted 1 line
Quoted 1 line
[ 7815.800001] R13: 00000719439890f1 R14: 0000000000000000 R15:
ffffffff80664d90Quoted 1 line
Quoted 1 line
[ 7815.807436] FS: 0000000040112950(0063) GS:ffffffff805d6000(0000)knlGS:0000000000000000
Quoted 2 lines
Quoted 2 lines
[ 7815.815909] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7815.821915] CR2: 00002b83d55aec80 CR3: 000000003dff8000 CR4:
00000000000006e0Quoted 1 line
Quoted 1 line
[ 7815.829357] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000
Quoted 1 line
Quoted 1 line
[ 7815.836786] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:0000000000000400
Quoted 1 line
Quoted 1 line
[ 7815.844238] Process WORK_TASK_2056 (pid: 6481, threadinfo
ffff810013f78000, taskffff81003e082780)Quoted 1 line
Quoted 1 line
[ 7815.853584] Stack: ffff810001013180 00000718f7bcb1dd
ffffffff80664db0ffffffff80238af8Quoted 1 line
Quoted 1 line
[ 7815.862131] ffffffff80664d90 ffffffff80664d90 00000719439890f1
ffff81000100a6c0Quoted 1 line
Quoted 1 line
[ 7815.869974] ffff8100010087a0 ffff81000100a5c0 00000719439890f10000000000000000
Quoted 7 lines
Quoted 7 lines
[ 7815.877667] Call Trace: [ 7815.880441] <IRQ> [<ffffffff80238af8>] scheduler_tick+0xf8/0x140 [ 7815.886908] [<ffffffff8025e89b>] tick_sched_timer+0x7b/0x170 [ 7815.892929] [<ffffffff8025900f>] hrtimer_interrupt+0x12f/0x1e0 [ 7815.899137] [<ffffffff80220857>] smp_apic_timer_interrupt+0x37/0x60 [ 7815.905752] [<ffffffff8020c9f1>] common_interrupt+0x61/0x7d [ 7815.911779] [<ffffffff802777e0>] __ipipe_sync_stage+0x350/0x355Quoted 8 lines
Quoted 8 lines
[ 7815.918085] [<ffffffff80220820>] smp_apic_timer_interrupt+0x0/0x60 [ 7815.924655] [<ffffffff802777e5>] __xirq_end+0x0/0x85 [ 7815.929964] [<ffffffff80220820>] smp_apic_timer_interrupt+0x0/0x60 [ 7815.936587] [<ffffffff80226b01>] __ipipe_handle_irq+0x91/0x250 [ 7815.942774] [<ffffffff8020c9f1>] common_interrupt+0x61/0x7d [ 7815.948673] <EOI> [ 7815.950909] [ 7815.950909] Code: 0f 0b eb fe 66 66 66 2e 0f 1f 84 00 00 00 00 00 4157 41 56
Quoted 1 line
Quoted 1 line
[ 7815.960491] RIP [<ffffffff80256e20>]
run_posix_cpu_timers+0x810/0x820Quoted 3 lines
Quoted 3 lines
[ 7815.967284] RSP <ffffffff80664d70> [ 7815.970982] ---[ end trace d192885d9858c4b2 ]--- [ 7815.975820] Kernel panic - not syncing: Aiee, killing interrupt
Quoted 8 lines
handler!
Quoted 4 lines
That's now a totally different spot, and it makes me wonder if can reproduce all this troubles with vanilla Xenomai and without your driver being loaded...
We measure data from our unit connected through rtnet or with a PCI card. It's independent if we use one way or another, these kernel panics appear in both setups. So rtnet and our module are not involved. But it does depend on the measuring frequency and the amount of measured data in every cycle.
We likely see some race that causes weird memory corruptions. Its probability often increases when the code execution frequency raises.
However, reducing the test case is very important now to reduce the search domain for this issue. E.g. try to fake peripheral access as far as possible, unloading the unused driver and only leaving the test program behind that is executable on arbitrary Xenomai installation (maybe finally on one of my boxes...).
TiA,
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 9 lines · Jan Kiszka
We likely see some race that causes weird memory corruptions. Its probability often increases when the code execution frequency raises.
However, reducing the test case is very important now to reduce the search domain for this issue. E.g. try to fake peripheral access as far as possible, unloading the unused driver and only leaving the test program behind that is executable on arbitrary Xenomai installation (maybe finally on one of my boxes...).
I'm not sure if I will be able to reduce the software. It's dependent on hardware and it's controlled from another windows computer with GUI and control application. And to check if the error is still there usually takes couple of days. I ran a test during last weekend (and nothing wrong happened). But the /proc/xenomai/stat output is strange. Probably some type cast error, because 18446744071739514846 = 0xFFFFFFFF8A939FDE and the appropriate value perhaps should be 0x000000008A939FDE = 2324930526.
CPU PID MSW CSW PF STAT %CPU NAME 0 0 0 18446744071739514846 0 00500088 69.8 ROOT/0 1 0 0 18446744071675175740 0 00500080 23.2 ROOT/1 0 5299 0 351459 0 00300182 0.0 LOGGER_TASK_1804289383 0 5100 8 283613 0 00300186 0.0 0 5317 0 40591 0 00300182 0.0 0 5034 2 2330696 0 00300184 0.0 MAIN_TASK_2056 0 5318 5 18446744071736105613 3 00300180 29.5 REG_TASK_2056 0 5319 28 36 0 00300182 0.0 WORK_TASK_2056 0 5321 38926 39159 0 00300380 0.0 CERECV_2056 0 5323 1159385 2438330 0 00300181 0.0 CESEND_2056 1 5710 0 18446744071675175740 0 00300184 76.8 HARDWARE_KERNEL 0 0 0 18446744071964064315 0 00000000 0.7 IRQ520: [timer] 1 0 0 232145209 0 00000000 0.0 IRQ520: [timer]
My theory is, that a occasional "longer" work or system call usage in the real-time task corrupts the rest of the system (under some special circumstances).
Petr
Quoted 13 lines · Petr Cervenka
Quoted 9 lines · Jan Kiszka
We likely see some race that causes weird memory corruptions. Its probability often increases when the code execution frequency raises.
However, reducing the test case is very important now to reduce the search domain for this issue. E.g. try to fake peripheral access as far as possible, unloading the unused driver and only leaving the test program behind that is executable on arbitrary Xenomai installation (maybe finally on one of my boxes...).
I'm not sure if I will be able to reduce the software. It's dependent on hardware and it's controlled from another windows computer with GUI and control application. And to check if the error is still there usually takes couple of days. I ran a test during last weekend (and nothing wrong happened). But the
/proc/xenomai/statoutput is strange. Probably some type cast error, because 18446744071739514846 =0xFFFFFFFF8A939FDEand the appropriate value perhaps should be0x000000008A939FDE= 2324930526.
Quoted 14 lines
CPU PID MSW CSW PF STAT %CPU NAME 0 0 0 18446744071739514846 0 00500088 69.8 ROOT/0 1 0 0 18446744071675175740 0 00500080 23.2 ROOT/1 0 5299 0 351459 0 00300182 0.0 LOGGER_TASK_1804289383 0 5100 8 283613 0 00300186 0.0 0 5317 0 40591 0 00300182 0.0 0 5034 2 2330696 0 00300184 0.0 MAIN_TASK_2056 0 5318 5 18446744071736105613 3 00300180 29.5 REG_TASK_2056 0 5319 28 36 0 00300182 0.0 WORK_TASK_2056 0 5321 38926 39159 0 00300380 0.0 CERECV_2056 0 5323 1159385 2438330 0 00300181 0.0 CESEND_2056 1 5710 0 18446744071675175740 0 00300184 76.8 HARDWARE_KERNEL 0 0 0 18446744071964064315 0 00000000 0.7 IRQ520: [timer] 1 0 0 232145209 0 00000000 0.0 IRQ520: [timer]
OK, at least this bug is a bit easier to fix. Please try this patch (which also takes the chance and extends the range of our stat counters a bit):
include/nucleus/stat.h +4 -4
@@ -84,20 +84,20 @@ do { \typedef struct xnstat_counter { -int counter; +unsigned long counter; }xnstat_counter_t ; -static inline int xnstat_counter_inc (xnstat_counter_t *c) +static inline unsigned long xnstat_counter_inc (xnstat_counter_t *c) {return c->counter++; } -static inline int xnstat_counter_get (xnstat_counter_t *c) +static inline unsigned long xnstat_counter_get (xnstat_counter_t *c) {return c->counter; } -static inline void xnstat_counter_set (xnstat_counter_t *c,int value) +static inline void xnstat_counter_set (xnstat_counter_t *c,unsigned long value) { c->counter = value; }
Quoted 2 lines
My theory is, that a occasional "longer" work or system call usage in the real-time task corrupts the rest of the system (under some special circumstances).
Yes, some nasty memory corruption is probably the reason. And that is always hard to track down, specifically if it happens very unpredictably. Nevertheless, if the issue continues to bug you, you will not get around reducing the test case and trying to increase its occurrence probability.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
[Xenomai-help] Segmentation error by heavy dynamic RT_QUEUE usage
Hello,
I wanted to make an small example to find the kernel panic (and I failed with it). But during my tests I found another possible error. I made a small application (as netbeans c++ project) with two tasks:
1) server task with its RT_QUEUE waiting for a request.
2) client task which creates RT_QUEUES for response and sends requests to the server task
Quoted 1 line
From time to time I get an segmentation error.
It's always in the server task, when the server binds the clients queue, allocates a message buffer in it. It seems when the server starts to work with this buffer, the client could already close the queue.
But this shouldn't be possible, because normally any attempt to close a queue binded by someone else ends with -EBUSY error. The error needs some time to produce and 2 CPUs (cores). One for server and one for client.
My configuration(s):
Athlon XP 2600GHz X86_64
kernel 2.6.24 (and 2.6.25.11)
adeos 2.6.24 2.0-03 (and 2.0-07)
xenomai 2.4.1 and 2.4.4
I'm sending also examples of the execution script and proper input.txt file
both of them should be much longer (input.txt could be several MB)!!!!
In the attachement there is also disassemble of my executable
And finally, one of the segmentation error messages:
[ 2553.818731] QT_SERVER[5919]: segfault at 2aaaaac96800 rip 4022b5 rsp 4000fe00 error 6
But there are more types, but allways when working with the allocated send buffer. I know, I'm annoying, but I can't help myself.... ;-)
Petr
send 490000
recv
echo 490000
sleep 100
send 490000
recv
echo 490000
sleep 100
send 490000
recv
echo 490000
sleep 100
send 490000
recv
echo 490000
sleep 100
Re: [Xenomai-help] Segmentation error by heavy dynamic RT_QUEUE usage
Quoted 19 lines · Petr Cervenka
Hello,
I wanted to make an small example to find the kernel panic (and I failed with it). But during my tests I found another possible error. I made a small application (as netbeans c++ project) with two tasks:
1) server task with itsRT_QUEUEwaiting for a request.
2) client task which createsRT_QUEUESfor response and sends requests to the server taskQuoted 1 line
From time to time I get an segmentation error.
It's always in the server task, when the server binds the clients queue, allocates a message buffer in it. It seems when the server starts to work with this buffer, the client could already close the queue.
But this shouldn't be possible, because normally any attempt to close a queue binded by someone else ends with-EBUSYerror. The error needs some time to produce and 2 CPUs (cores). One for server and one for client.
My configuration(s):
Athlon XP 2600GHzX86_64
kernel 2.6.24 (and 2.6.25.11)
adeos 2.6.24 2.0-03 (and 2.0-07)
xenomai 2.4.1 and 2.4.4
I'm sending also examples of the execution script and proper input.txt file
both of them should be much longer (input.txt could be several MB)!!!!
In the attachement there is also disassemble of my executable
And finally, one of the segmentation error messages:
Quoted 3 lines
[ 2553.818731] QT_SERVER[5919]: segfault at 2aaaaac96800 rip 4022b5 rsp 4000fe00 error 6But there are more types, but allways when working with the allocated send buffer. I know, I'm annoying, but I can't help myself.... ;-)
Yeah, but I can't help running useful test code people cared to write either, so that's ok.
There was a silly bug in the userland wrapper, unmapping the memory pool from the application process, albeit the syscall just denied deletion (-EBUSY). This issue also affects RT_HEAP objects the very same way.
Fixed in both trees. Thanks for narrowing the issue.
Note: creating / binding to a _shared_ queue switches the caller to secondary mode, because in both cases, we need to use regular kernel services to mmap() the memory pool to the application process.
skins/native/queue.c +4 -7
@@ -114,21 +114,18 @@ {int err; - err =__real_munmap (q->mapbase, q->mapsize); - -if (err) -return -EINVAL ; - err =XENOMAI_SKINCALL1 (__native_muxid, __native_queue_delete, q); -if (err)return err; +if (__real_munmap (q->mapbase, q->mapsize)) + err = -errno; + q->opaque =XN_NO_HANDLE ; q->mapbase =NULL ; q->mapsize =0 ; -return 0 ; +return err; }void *rt_queue_alloc (RT_QUEUE *q,size_t size)
PS: careful with the subject line, heavy / light RT_QUEUE usage is irrelevant wrt this bug, it is purely a matter of sequence (queue_create -> queue_bind -> queue_delete) that triggers the rt_queue_delete() wrapper issue.
Signature · 1 line
Philippe.
PATCH 1/1 Fix stat overruns on 64-bit (was: [Xenomai-help] Kernel panic: not syncing)
In reply to Jan KiszkaQuoted 41 lines · Jan Kiszka
Quoted 16 lines · Petr Cervenka
I ran a test during last weekend (and nothing wrong happened). But the
/proc/xenomai/statoutput is strange. Probably some type cast error, because 18446744071739514846 =0xFFFFFFFF8A939FDEand the appropriate value perhaps should be0x000000008A939FDE= 2324930526.CPU PID MSW CSW PF STAT %CPU NAME 0 0 0 18446744071739514846 0 00500088 69.8 ROOT/0 1 0 0 18446744071675175740 0 00500080 23.2 ROOT/1 0 5299 0 351459 0 00300182 0.0 LOGGER_TASK_1804289383 0 5100 8 283613 0 00300186 0.0 0 5317 0 40591 0 00300182 0.0 0 5034 2 2330696 0 00300184 0.0 MAIN_TASK_2056 0 5318 5 18446744071736105613 3 00300180 29.5 REG_TASK_2056 0 5319 28 36 0 00300182 0.0 WORK_TASK_2056 0 5321 38926 39159 0 00300380 0.0 CERECV_2056 0 5323 1159385 2438330 0 00300181 0.0 CESEND_2056 1 5710 0 18446744071675175740 0 00300184 76.8 HARDWARE_KERNEL 0 0 0 18446744071964064315 0 00000000 0.7 IRQ520: [timer] 1 0 0 232145209 0 00000000 0.0 IRQ520: [timer]OK, at least this bug is a bit easier to fix. Please try this patch (which also takes the chance and extends the range of our stat counters a bit):
Index:
xenomai/include/nucleus/stat.h
===================================================================include/nucleus/stat.h +2
-3@@ -84,20 +84,20 @@ do { \typedef struct xnstat_counter { -int counter; +unsigned long counter; }xnstat_counter_t ; -static inline int xnstat_counter_inc (xnstat_counter_t *c) +static inline unsigned long xnstat_counter_inc (xnstat_counter_t *c) {return c->counter++; } -static inline int xnstat_counter_get (xnstat_counter_t *c)
include/nucleus/stat.h do { \ · line 103
Quoted 10 lines
include/nucleus/stat.h +2
-1+static inline unsigned long xnstat_counter_get (xnstat_counter_t *c) {return c->counter; } -static inline void xnstat_counter_set (xnstat_counter_t *c,int value) +static inline void xnstat_counter_set (xnstat_counter_t *c,unsigned long value) { c->counter = value; }
OK to apply those bits?
Jan
Re: [Xenomai-core] [PATCH] Fix stat overruns on 64-bit
Quoted 46 lines · Jan Kiszka
Quoted 45 lines · Jan Kiszka
Quoted 16 lines · Petr Cervenka
I ran a test during last weekend (and nothing wrong happened). But the
/proc/xenomai/statoutput is strange. Probably some type cast error, because 18446744071739514846 =0xFFFFFFFF8A939FDEand the appropriate value perhaps should be0x000000008A939FDE= 2324930526.CPU PID MSW CSW PF STAT %CPU NAME 0 0 0 18446744071739514846 0 00500088 69.8 ROOT/0 1 0 0 18446744071675175740 0 00500080 23.2 ROOT/1 0 5299 0 351459 0 00300182 0.0 LOGGER_TASK_1804289383 0 5100 8 283613 0 00300186 0.0 0 5317 0 40591 0 00300182 0.0 0 5034 2 2330696 0 00300184 0.0 MAIN_TASK_2056 0 5318 5 18446744071736105613 3 00300180 29.5 REG_TASK_2056 0 5319 28 36 0 00300182 0.0 WORK_TASK_2056 0 5321 38926 39159 0 00300380 0.0 CERECV_2056 0 5323 1159385 2438330 0 00300181 0.0 CESEND_2056 1 5710 0 18446744071675175740 0 00300184 76.8 HARDWARE_KERNEL 0 0 0 18446744071964064315 0 00000000 0.7 IRQ520: [timer] 1 0 0 232145209 0 00000000 0.0 IRQ520: [timer]OK, at least this bug is a bit easier to fix. Please try this patch (which also takes the chance and extends the range of our stat counters a bit):
Index:
xenomai/include/nucleus/stat.h
===================================================================include/nucleus/stat.h +3
-3@@ -84,20 +84,20 @@ do { \typedef struct xnstat_counter { -int counter; +unsigned long counter; }xnstat_counter_t ; -static inline int xnstat_counter_inc (xnstat_counter_t *c) +static inline unsigned long xnstat_counter_inc (xnstat_counter_t *c) {return c->counter++; } -static inline int xnstat_counter_get (xnstat_counter_t *c) +static inline unsigned long xnstat_counter_get (xnstat_counter_t *c) {return c->counter; }
Quoted 8 lines
include/nucleus/stat.h do { \ · line 103
Quoted 5 lines
include/nucleus/stat.h +1
-1-static inline void xnstat_counter_set (xnstat_counter_t *c,int value) +static inline void xnstat_counter_set (xnstat_counter_t *c,unsigned long value) { c->counter = value; }OK to apply those bits?
Sure. Please apply to both branches.
Quoted 10 lines
Jan
------------------------------------------------------------------------
_______________________________________________
Xenomai-core mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-core
Signature · 1 line
Philippe.