Am 25.10.2010 18:48, Philippe Gerum wrote: > On Wed, 2010-10-13 at 16:52 +0200, Philippe Gerum wrote: >>> >>> Should we test IPIPE_STALL_FLAG on all but current CPUs? >> >> That would solve this particular issue, but we should drain the pipeline >> out of any Xenomai critical section. The way it is done now may induce a >> deadlock (e.g. CPU0 waiting for CPU1 to acknowledge critical entry in >> ipipe_enter_critical when getting some IPI, and CPU1 waiting hw IRQs off >> for CPU0 to release the Xenomai lock that annoys us right now). >> >> I'll come up with something hopefully better and tested in the next >> days. >> > > Sorry for the lag. In case that helps, here is another approach, based > on telling the pipeline to ignore the irq about to be detached, so that > it passes all further occurrences down to the next domain, without
Err, won't this irritate that next domain, ie. won't Linux dump warnings about a spurious/unhandled IRQ? I think either the old handler shall receive the last event or no one. Why this complex solution, why not simply draining (via critical_enter or whatever) - but _after_ xnintr_irq_detach, ie. while the related resources are still valid? Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
