Jan Kiszka wrote: > ... > This indicates that we face an I-pipe bug: the scheduled Linux call on > relaxation of TASK2 and then later TASK1 somehow gets lost (there is no > rthal_apc_handler in the remaining trace).
I think I got it. No I-pipe bug, but one in the HAL.
What happened? A weird race caused by the unprotected optimisation to
only call rthal_schedule_irq() if there is no APC pending yet. This is
the constellation I finally worked out via instrumenting and tracing:
PRIO 1:
rthal_apc_schedule()
test&set rthal_apc_pending
(but no rthal_schedule_irq() yet)
-PREEMPTION-
PRIO 99:
...
rthal_apc_schedule()
test rthal_apc_pending
(already set => no
rthal_schedule_irq()!)
So, no one reported the ACP to I-pipe, and no one ever will in Nicolas
scenario - soft lock-up!
Nicolas, please give the attached patch a try. Your test is running fine
for me now.
At this chance: do we need rthal_apc_schedule() returning the previous
state at all? No current caller checks the return value. If it's OK to
clean this up, I will post a combined patch.
Jan
Index: ksrc/arch/generic/hal.c
===================================================================
--- ksrc/arch/generic/hal.c (Revision 1918)
+++ ksrc/arch/generic/hal.c (Arbeitskopie)
@@ -596,18 +596,19 @@ int rthal_apc_free(int apc)
int rthal_apc_schedule(int apc)
{
rthal_declare_cpuid;
+ int ret = 1;
if (apc < 0 || apc >= RTHAL_NR_APCS)
return -EINVAL;
rthal_load_cpuid(); /* Migration would be harmless here. */
- if (!test_and_set_bit(apc, &rthal_apc_pending[cpuid])) {
- rthal_schedule_irq(rthal_apc_virq);
- return 1;
- }
+ if (test_and_set_bit(apc, &rthal_apc_pending[cpuid]))
+ ret = 0; /* Already pending. */
+
+ rthal_schedule_irq(rthal_apc_virq);
- return 0; /* Already pending. */
+ return ret;
}
#ifdef CONFIG_PROC_FS
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
