From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4CAEC633.8040609@domain.hid> Date: Fri, 08 Oct 2010 09:20:19 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <20101007115728.GA24500@domain.hid> <4CADBDC2.8080600@domain.hid> <20101008070148.GB2255@domain.hid> In-Reply-To: <20101008070148.GB2255@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] kernel oopses when killing realtime task List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Machek Cc: Jan Kiszka , xenomai@xenomai.org 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.