Thanks a lot for your attention. And sorry for my poor english. I change my context into a real RT context and my problem disappears.
Nevertheless, I have other questions about the IRQ management. In fact, after executing my software application (so after the rtdm_close call, and so the free irq), I obtain a syslog message : kernel Disabling IRQ #11. This message doesn't affect my software if I run it again, but may be there are some side effect. In dmesg, the following error message appears : irq 11: nobody cared (try booting with the "irqpoll" option). In my open function I call : - request_region - rtdm_irq_request In my close function I call : - rtdm_irq_free - release_region May be there is a function to call to avoid this disabling irq ? Moreover, when I'm using my discrets I/O driver (on the IRQ 11) and I add an USB Key (on this IRQ 11) the software freeze. Note that my USB Key works normaly before I call my open function, and doesn't work after my software execution, may be because of the Disabling IRQ. Note that the freeze appears with the 16550A rtdm driver use. For example, when my keyboard irq is the same as the seria board irq, the computer freeze when the driver is running and the keyboard is using at the same moment. I think that the linux irq and xenomai irq are not usable at the same time ! Note that my kernel is configured with shared interrupt. Guillaume. -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : mercredi 14 mai 2008 21:35 À : DOURNES Guillaume Cc : [email protected] Objet : Re: [Xenomai-help] Interrupt management under rtdm driver Jan Kiszka wrote: > DOURNES Guillaume wrote: >> Since I add the watchdog option in my kernel configuration, The software >> doesn't block. >> But I obtain an EPREM (-1) error on the second call of rtdm_event_timedwait, >> and in dmesg : Xenomai: assertion failed at >> kernel/xenomai/skins/rtdm/drvlib.c:919 (!xnpod_unblockable_p()). > > See, that is interesting. > >> I don't understand why I have this error, because the rtdm_event_timedwait >> is used as the 16550A rtserial rtdm driver. And I use this rtserial driver, >> and it works. >> Note that this problem doesn't appears when I call rt_task_suspend just >> after my rtdm_event_timedwait, and I resume the task by a gets. > > After having a look at your driver source meanwhile, the problem is > that you register your IOCTL handler also for handling invocation from > non-RT > (precisely: "secondary") context. But rtdm_event_timedwait always > requires primary (RT) context. That is something you either have to > check in the IOCTL handler before trying to block a caller - or you > simply do not register for nrt_ioctl (or use a different handler for > the set of IOCTLs in that context). > > The reason that suspending the caller made this issue go away was that > you have several plain Linux services in your RT loop that switches > the caller automatically to secondary mode. Thus the first IOCTL > succeeded, but the second failed after re-entering it now as a plain Linux > caller. ...But suspending the thread shortly before IOCTL re-entry automatically switch it back into the right (==RT) context. Jan _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
