Philippe Gerum wrote:
> On Fri, 2007-05-25 at 15:55 +0200, Jan Kiszka wrote:
>>Gilles Chanteperdrix wrote:
>>>Jan Kiszka wrote:
>>>>People, we have some new troubles:
>>>>I'm reproducibly getting recursive faults on termination of cyclictest
>>>>via ^C. It's all standard here: ipipe 1.8-02, Xenomai trunk #2469, no
>>>>weird patches of mine.
>>>>Something goes utterly wrong, the debugger currently points into
>>>>xnshadow_relax->rpi_push, and there into some queuing operation. Note
>>>>that I have XENO_OPT_SCALABLE_SCHED on in my config, also
>>>>XENO_OPT_PRIOCPL. Without XENO_OPT_SCALABLE_SCHED, things seems to work
>>>>find. Who did last work on this? What was fixed?
>>>Looking at svn log, you did the last modification. What about activating
>>>queue debugging ?
>>Well, I remember that 64-bit issue now, but it was my patch IIRC.
>>Anyway, good suggestion:
>>T: 0 ( 824) P:99 I: 1000 C: 1483 Min: 3 Act: 349 Avg:
>>1602 Max: 3240
>>[ 474.912841] Xenomai: fatal: corrupted queue, qslot->elems=0,
>>qslot=c0614a28 at include/xenomai/nucleus/queue.h:684
>>[ 474.912921] CPU PID PRI TIMEOUT STAT NAME
>>[ 474.912941] 0 0 -1 0 00500088 ROOT
>>[ 474.912960] 0 823 0 0 00300380 cyclictest
>>[ 474.912980] > 0 824 0 0 00300180 cyclictest
>>[ 474.913000] Master time base: clock=1043585105469
>>[ 474.915241] c11e7eb4 00000000 00000000 c0614a28 c11e7ed8 c0104c6e
>>[ 474.915762] 00000103 c11e7f18 c0154f02 c033fd86 c115c000 c0614a28
>>[ 474.916378] c015657d 00000000 c1180b30 ffffffff c1180d94 00000000
>>[ 474.916874] Call Trace:
>>[ 474.917034] [<c010451a>] show_trace_log_lvl+0x1a/0x30
>>[ 474.917422] [<c01045e1>] show_stack_log_lvl+0xb1/0xe0
>>[ 474.917693] [<c0104c6e>] show_stack+0x2e/0x40
>>[ 474.917920] [<c0154f02>] rpi_push+0x192/0x3a0
>>[ 474.918146] [<c0156a30>] xnshadow_relax+0x50/0x1c0
>>[ 474.918394] [<c01570c0>] hisyscall_event+0xd0/0x290
>>[ 474.918647] [<c0142a2e>] __ipipe_dispatch_event+0x8e/0x140
>>[ 474.918917] [<c010d97e>] __ipipe_syscall_root+0x3e/0xf0
>>[ 474.919292] [<c0102e59>] system_call+0x29/0x41
>>[ 474.919534] =======================
> Yeah. This is the exact bug I told you I was chasing some moons ago on
> qemu/x86_64 and which I can't reproduce anywhere else (on real hw for
> instance), glad to see I'm not alone in the twilight zone anymore. :o)
> (Btw, this issue predates any recent change; this is something I've seen
> popping up more than six weeks ago on my setup).
A recent change that might change the behaviour is the direct tsc access
by clock_gettime in user-space. This may make the bug win a race.
Xenomai-core mailing list