Jan Kiszka wrote:
Philippe Gerum wrote:

Jan Kiszka wrote:

Attached is an ipipe-freeze of the frozen system. It's taken at the time
the main thread of the terminating application has successfully
rt_task_join'ed the last remaining RT-thread. I took 2000 trace points
before and after that point and additionally instrumented
rthal_timer_program_shot() (special trace 0x01, the argument is the
delay). The interesting stuff happens around 600 us after the freeze: it
seems the scheduled Linux timer arrives then but doesn't get much
attention beyond from ipipe.

Any idea what to look for next? I have a "perfect" test system now,
though I still see no light at the end of the tunnel how to export it to
other boxes.

Enough for today.


PS: This trace was taken over 2.6.15 to exclude any issues with the new
2.6.16. Both kernels show the same effect.

Does this patch make any difference?

--- ipipe-root.c~    2006-01-31 09:55:44.000000000 +0100
+++ ipipe-root.c    2006-04-06 17:01:49.000000000 +0200
@@ -328,9 +328,8 @@
        /* Only sync virtual IRQs here, so that we don't recurse
           indefinitely in case of an external interrupt flood. */

-        if ((ipipe_root_domain->cpudata[cpuid].
-             irq_pending_hi & IPIPE_IRQMASK_VIRT) != 0)
-            __ipipe_sync_stage(IPIPE_IRQMASK_VIRT);
+        if (ipipe_root_domain->cpudata[cpuid].irq_pending_hi != 0)
+            __ipipe_sync_stage(IPIPE_IRQMASK_ANY);


That's good news, actually. I would have been quite embarrased if it did it.

Where should I put my finger on to find out what's happening?

It seems that the pipeline log is not synced by __ipipe_unstall_iret_root.
We need to know why. Question: is the root stage stalled or unstalled by this
routine during the latest call before the box freezes?

PS: it would be nice to display the status of the current stage
(stalled/unstalled) and the one of the hw interrupt bit, for each trace.




Xenomai-core mailing list

Reply via email to