Pavel Machek wrote:
> Hi!
>
>>> I have... quite an interesting setup here.
>>>
>>> SMP machine, with special PCI card; that card has GPIOs and serial
>>> ports. Unfortunately, there's only one interrupt, shared between
>>> serials and GPIO pins, and serials are way too complex to be handled
>>> by realtime layer.
>>>
>>> So I ended up with
>>>
>>> // we also have an interrupt handler:
>>>
>>>
>>> ret = rtdm_irq_request(&my_context->irq_handle,
>>> gpio_rt_config.irq, demo_interrupt,
>>> RTDM_IRQTYPE_SHARED,
>>> context->device->proc_name, my_context);
>>>
>>> and
>>>
>>> static int demo_interrupt(rtdm_irq_t *irq_context)
>>> {
>>> struct demodrv_context *ctx;
>>> int dev_id;
>>> int ret = RTDM_IRQ_HANDLED; // usual return value
>>>
>>>
>>> unsigned pending, output;
>>>
>>> ctx = rtdm_irq_get_arg(irq_context, struct demodrv_context);
>>> dev_id = ctx->dev_id;
>>>
>>> if (!ctx->ready) {
>>> printk(KERN_CRIT "Unexpected interrupt\n");
>>> return XN_ISR_PROPAGATE;
>> Who sets ready and when? Looks racy.
>
> Debugging aid; yes, this one is racy.
>
>>> rtdm_lock_put(&ctx->lock);
>>>
>>> /* We need to propagate the interrupt, so that PMC-6L serials
>>>
>>>
>>> work. Result is that interrupt latencies can't be
>>>
>>>
>>> guaranteed when serials are in use. */
>>>
>>> return RTDM_IRQ_HANDLED;
>>> }
>>>
>>> Unregistration is:
>>> my_context->ready = 0;
>>> rtdm_irq_disable(&my_context->irq_handle);
>> Where is rtdm_irq_free? Again, this ready flag looks racy.
>
> Aha, sorry, I quoted wrong snippet. rtdm_irq_free() follows
> immediately, like this:
>
> int demo_close_rt(struct rtdm_dev_context *context,
> rtdm_user_info_t *user_info)
> {
> struct demodrv_context *my_context;
> rtdm_lockctx_t lock_ctx;
> // get the context
>
>
> my_context = (struct demodrv_context *)context->dev_private;
>
> // if we need to do some stuff with preemption disabled:
>
>
> rtdm_lock_get_irqsave(&my_context->lock, lock_ctx);
>
> my_context->ready = 0;
> rtdm_irq_disable(&my_context->irq_handle);
>
>
> // free irq in RTDM
>
>
> rtdm_irq_free(&my_context->irq_handle);
>
> // destroy our interrupt signal/event
>
>
> rtdm_event_destroy(&my_context->irq_event);
>
> // other stuff here
>
>
> rtdm_lock_put_irqrestore(&my_context->lock, lock_ctx);
>
> return 0;
> }
>
> Now... I'm aware that lock_get/put around irq_free should be
> unneccessary, as should be irq_disable and my ->ready flag. Those were
> my attempts to work around the problem. I'll attach the full source at
> the end.
>
>>> Unfortunately, when the userspace app is ran and killed repeatedly (so
>>> that interrupt is registered/unregistered all the time), I get
>>> oopses in __ipipe_dispatch_wired() -- it seems to call into the NULL
>>> pointer.
>>>
>>> I decided that "wired" interrupt when the source is shared between
>>> Linux and Xenomai, is wrong thing, so I disable "wired" interrupts
>>> altogether, but that only moved oops to __virq_end.
>> This is wrong. The only way to get a determistically shared IRQs across
>> domains is via the wired path, either using the pattern Gilles cited or,
>> in a slight variation, signaling down via a separate rtdm_nrtsig.
>
> For now, I'm trying to get it not to oops; deterministic latencies are
> the next topic :-(.
Another remark, Xenomai releases of a given branch are ABI and API
compatible, so, upgrade to the latest version of the 2.4 branch, which
is 2.4.9.1 will not hurt. In the same vein, I-pipe patches are backward
compatibles, so, upgrade to
http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.27-x86-2.2-03.patch
is recommended if it is not the I-pipe you are using.
It would be nice if you could at least test these versions, if they
work, we would know whether the issue you have has been solved since the
release of these versions.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
