* [Xenomai-help] Interrupt propagation question @ 2008-04-14 0:44 Tomas Kalibera 2008-04-14 7:26 ` Philippe Gerum 0 siblings, 1 reply; 5+ messages in thread From: Tomas Kalibera @ 2008-04-14 0:44 UTC (permalink / raw) To: xenomai Hi, I'm receiving interrupts in Xenomai user-domain using rt_intr_wait. What is the semantics of rt_intr_enable and rt_intr_disable ? And I_NOAUTOENA ? I used I_NOAUTOENA when calling rt_intr_create. I thought that after returning from rt_intr_wait, the interrupt would be disabled before I explicitly call rt_intr_enable. However, next call to rt_intr_wait happily returned with the next interrupt, as opposed to blocking indefinitely. Why ? Does rt_intr_wait automatically re-enable the interrupt ? I tried to intentionally loose interrupts - I called rt_intr_enable while handling an interrupt intentionally before making the hardware generate next one. Still, the next call to rt_intr_wait did return (the interrupt was not lost). How could this happen ? If interrupts are logged anyway, what the rt_intr_enable/disable does ? I read in the API documentation "Interrupt receipts are logged if they cannot be delivered immediately to some interrupt server task, so that a call to rt_intr_wait() <http://www.xenomai.org/documentation/branches/v2.4.x/html/api/group__interrupt.html#g222e6a9a681f83b13ed5b51021711f4d> might return immediately if an IRQ is already pending on entry of the service." How does Xenomai find out about this ? I mean, if a "interrupt server task" is not presently blocked in rt_intr_wait for a particular interrupt, how does Xenomai know that a task is actually an "interrupt server task" ? When does this association happen ? Does a call to rt_intr_create make Xenomai log interrupts for the domain from which rt_intr_create was called ? Thanks ! Tomas ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-help] Interrupt propagation question 2008-04-14 0:44 [Xenomai-help] Interrupt propagation question Tomas Kalibera @ 2008-04-14 7:26 ` Philippe Gerum 2008-04-14 17:14 ` Tomas Kalibera 0 siblings, 1 reply; 5+ messages in thread From: Philippe Gerum @ 2008-04-14 7:26 UTC (permalink / raw) To: Tomas Kalibera; +Cc: xenomai Tomas Kalibera wrote: > Hi, > > I'm receiving interrupts in Xenomai user-domain using rt_intr_wait. What > is the semantics of rt_intr_enable and rt_intr_disable ? And I_NOAUTOENA ? > > I used I_NOAUTOENA when calling rt_intr_create. I thought that after > returning from rt_intr_wait, the interrupt would be disabled before I > explicitly call rt_intr_enable. However, next call to rt_intr_wait > happily returned with the next interrupt, as opposed to blocking > indefinitely. Why ? Does rt_intr_wait automatically re-enable the > interrupt ? > > I tried to intentionally loose interrupts - I called rt_intr_enable > while handling an interrupt intentionally before making the hardware > generate next one. Still, the next call to rt_intr_wait did return (the > interrupt was not lost). How could this happen ? If interrupts are > logged anyway, what the rt_intr_enable/disable does ? > > I read in the API documentation > > "Interrupt receipts are logged if they cannot be delivered immediately > to some interrupt server task, so that a call to rt_intr_wait() > <http://www.xenomai.org/documentation/branches/v2.4.x/html/api/group__interrupt.html#g222e6a9a681f83b13ed5b51021711f4d> > might return immediately if an IRQ is already pending on entry of the > service." > > How does Xenomai find out about this ? I mean, if a "interrupt server > task" is not presently blocked in rt_intr_wait for a particular > interrupt, how does Xenomai know that a task is actually an "interrupt > server task" ? When does this association happen ? Does a call to > rt_intr_create make Xenomai log interrupts for the domain from which > rt_intr_create was called ? > This call delivers interrupts to the Xenomai domain, only. For the rest, have a look at ksrc/skins/native/syscall.c, __rt_intr_wait, and __rt_intr_handler. > Thanks ! > Tomas > > > > > > > _______________________________________________ > Xenomai-help mailing list > Xenomai-help@domain.hid > https://mail.gna.org/listinfo/xenomai-help > -- Philippe. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-help] Interrupt propagation question 2008-04-14 7:26 ` Philippe Gerum @ 2008-04-14 17:14 ` Tomas Kalibera 2008-04-14 20:33 ` Philippe Gerum 0 siblings, 1 reply; 5+ messages in thread From: Tomas Kalibera @ 2008-04-14 17:14 UTC (permalink / raw) To: rpm; +Cc: xenomai Hi, so I've gone through the sources and made my guesses. When called from user space, rt_intr_create results in a kernel-space handler being installed using kernel-space rt_intr_create. The kernel handler only counts received interrupts, exiting as soon as the count is updated. The kernel handler is called with the interrupt disabled. On return, it uses the I_NOAUTOENA flag from the user space call to rt_intr_create. When the flag is set, the interrupts should stay disabled at hardware level unless explicitly enabled by application. If rt_intr_wait is called from user space, it blocks until interrupt count is >=1, then returns the interrupt count. Enabling/disabling interrupts has thus no direct impact on rt_intr_wait returning - if some interrupts are left to handle, rt_intr_wait will return even if the interrupt is disabled. As far as my guesses based on the code are correct, rt_intr_enable and rt_intr_disable called from user space should do end up in the interrupts being enabled/disabled at hardware level. A simple example however does not seem to follow this - I disable interrupts, do not enable it, and they're still received. Why could this be happening ? Is there a way to inquire if the interrupt is really disabled, at application level ? Tomas Philippe Gerum wrote: > Tomas Kalibera wrote: > >> Hi, >> >> I'm receiving interrupts in Xenomai user-domain using rt_intr_wait. What >> is the semantics of rt_intr_enable and rt_intr_disable ? And I_NOAUTOENA ? >> >> I used I_NOAUTOENA when calling rt_intr_create. I thought that after >> returning from rt_intr_wait, the interrupt would be disabled before I >> explicitly call rt_intr_enable. However, next call to rt_intr_wait >> happily returned with the next interrupt, as opposed to blocking >> indefinitely. Why ? Does rt_intr_wait automatically re-enable the >> interrupt ? >> >> I tried to intentionally loose interrupts - I called rt_intr_enable >> while handling an interrupt intentionally before making the hardware >> generate next one. Still, the next call to rt_intr_wait did return (the >> interrupt was not lost). How could this happen ? If interrupts are >> logged anyway, what the rt_intr_enable/disable does ? >> >> I read in the API documentation >> >> "Interrupt receipts are logged if they cannot be delivered immediately >> to some interrupt server task, so that a call to rt_intr_wait() >> <http://www.xenomai.org/documentation/branches/v2.4.x/html/api/group__interrupt.html#g222e6a9a681f83b13ed5b51021711f4d> >> might return immediately if an IRQ is already pending on entry of the >> service." >> >> How does Xenomai find out about this ? I mean, if a "interrupt server >> task" is not presently blocked in rt_intr_wait for a particular >> interrupt, how does Xenomai know that a task is actually an "interrupt >> server task" ? When does this association happen ? Does a call to >> rt_intr_create make Xenomai log interrupts for the domain from which >> rt_intr_create was called ? >> >> > > This call delivers interrupts to the Xenomai domain, only. > > For the rest, have a look at ksrc/skins/native/syscall.c, __rt_intr_wait, and > __rt_intr_handler. > > >> Thanks ! >> Tomas >> >> >> >> >> >> >> _______________________________________________ >> Xenomai-help mailing list >> Xenomai-help@domain.hid >> https://mail.gna.org/listinfo/xenomai-help >> >> > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-help] Interrupt propagation question 2008-04-14 17:14 ` Tomas Kalibera @ 2008-04-14 20:33 ` Philippe Gerum [not found] ` <4803D33B.5050507@domain.hid> 0 siblings, 1 reply; 5+ messages in thread From: Philippe Gerum @ 2008-04-14 20:33 UTC (permalink / raw) To: Tomas Kalibera; +Cc: xenomai Tomas Kalibera wrote: > > Hi, > > so I've gone through the sources and made my guesses. When called from > user space, rt_intr_create results in a kernel-space handler being > installed using kernel-space rt_intr_create. The kernel handler only > counts received interrupts, exiting as soon as the count is updated. The > kernel handler is called with the interrupt disabled. On return, it uses > the I_NOAUTOENA flag from the user space call to rt_intr_create. When > the flag is set, the interrupts should stay disabled at hardware level > unless explicitly enabled by application. > > If rt_intr_wait is called from user space, it blocks until interrupt > count is >=1, then returns the interrupt count. Enabling/disabling > interrupts has thus no direct impact on rt_intr_wait returning - if some > interrupts are left to handle, rt_intr_wait will return even if the > interrupt is disabled. > > As far as my guesses based on the code are correct, rt_intr_enable and > rt_intr_disable called from user space should do end up in the > interrupts being enabled/disabled at hardware level. A simple example > however does not seem to follow this - I disable interrupts, do not > enable it, and they're still received. Why could this be happening ? Is > there a way to inquire if the interrupt is really disabled, at > application level ? > What do $ cat /proc/interrupts and $ cat /proc/xenomai/irq say? > Tomas > > Philippe Gerum wrote: >> Tomas Kalibera wrote: >> >>> Hi, >>> >>> I'm receiving interrupts in Xenomai user-domain using rt_intr_wait. >>> What is the semantics of rt_intr_enable and rt_intr_disable ? And >>> I_NOAUTOENA ? >>> >>> I used I_NOAUTOENA when calling rt_intr_create. I thought that after >>> returning from rt_intr_wait, the interrupt would be disabled before I >>> explicitly call rt_intr_enable. However, next call to rt_intr_wait >>> happily returned with the next interrupt, as opposed to blocking >>> indefinitely. Why ? Does rt_intr_wait automatically re-enable the >>> interrupt ? >>> >>> I tried to intentionally loose interrupts - I called rt_intr_enable >>> while handling an interrupt intentionally before making the hardware >>> generate next one. Still, the next call to rt_intr_wait did return >>> (the interrupt was not lost). How could this happen ? If interrupts >>> are logged anyway, what the rt_intr_enable/disable does ? >>> >>> I read in the API documentation >>> >>> "Interrupt receipts are logged if they cannot be delivered >>> immediately to some interrupt server task, so that a call to >>> rt_intr_wait() >>> <http://www.xenomai.org/documentation/branches/v2.4.x/html/api/group__interrupt.html#g222e6a9a681f83b13ed5b51021711f4d> >>> might return immediately if an IRQ is already pending on entry of the >>> service." >>> >>> How does Xenomai find out about this ? I mean, if a "interrupt server >>> task" is not presently blocked in rt_intr_wait for a particular >>> interrupt, how does Xenomai know that a task is actually an >>> "interrupt server task" ? When does this association happen ? Does a >>> call to rt_intr_create make Xenomai log interrupts for the domain >>> from which rt_intr_create was called ? >>> >>> >> >> This call delivers interrupts to the Xenomai domain, only. >> >> For the rest, have a look at ksrc/skins/native/syscall.c, >> __rt_intr_wait, and >> __rt_intr_handler. >> >> >>> Thanks ! >>> Tomas >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Xenomai-help mailing list >>> Xenomai-help@domain.hid >>> https://mail.gna.org/listinfo/xenomai-help >>> >>> >> >> >> > > -- Philippe. ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <4803D33B.5050507@domain.hid>]
[parent not found: <48045AEF.5000005@domain.hid>]
* Re: [Xenomai-help] Interrupt propagation question [not found] ` <48045AEF.5000005@domain.hid> @ 2008-04-15 17:08 ` Tomas Kalibera 0 siblings, 0 replies; 5+ messages in thread From: Tomas Kalibera @ 2008-04-15 17:08 UTC (permalink / raw) To: rpm; +Cc: xenomai Philippe Gerum wrote: > The serial interrupt on your box is edge, so it won't be masked on arrival but > only acked. That behaviour is therefore normal. > I see. So to disable/enable interrupts, Xenomai does not talk directly to the controller, but to (non-Xenomai) Linux kernel. Which, as it uses split-handlers, acks edge interrupts, but does not mask them, to minimize the chance they're lost. So if I wanted to do non-split handling in Xenomai primary user-space domain, I'd probably have to modify the kernel anyway to mask edge interrupts, too.. When I disable IO-APIC in Linux kernel, the serial line uses XT-PIC, and interrupts are enabled/disabled using rt_intr_enable/disable as expected. Tomas > >> Tomas >> >> >> >> >> >>> >>> >>>> Tomas >>>> >>>> Philippe Gerum wrote: >>>> >>>> >>>>> Tomas Kalibera wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm receiving interrupts in Xenomai user-domain using rt_intr_wait. >>>>>> What is the semantics of rt_intr_enable and rt_intr_disable ? And >>>>>> I_NOAUTOENA ? >>>>>> >>>>>> I used I_NOAUTOENA when calling rt_intr_create. I thought that after >>>>>> returning from rt_intr_wait, the interrupt would be disabled before I >>>>>> explicitly call rt_intr_enable. However, next call to rt_intr_wait >>>>>> happily returned with the next interrupt, as opposed to blocking >>>>>> indefinitely. Why ? Does rt_intr_wait automatically re-enable the >>>>>> interrupt ? >>>>>> >>>>>> I tried to intentionally loose interrupts - I called rt_intr_enable >>>>>> while handling an interrupt intentionally before making the hardware >>>>>> generate next one. Still, the next call to rt_intr_wait did return >>>>>> (the interrupt was not lost). How could this happen ? If interrupts >>>>>> are logged anyway, what the rt_intr_enable/disable does ? >>>>>> >>>>>> I read in the API documentation >>>>>> >>>>>> "Interrupt receipts are logged if they cannot be delivered >>>>>> immediately to some interrupt server task, so that a call to >>>>>> rt_intr_wait() >>>>>> <http://www.xenomai.org/documentation/branches/v2.4.x/html/api/group__interrupt.html#g222e6a9a681f83b13ed5b51021711f4d> >>>>>> >>>>>> might return immediately if an IRQ is already pending on entry of the >>>>>> service." >>>>>> >>>>>> How does Xenomai find out about this ? I mean, if a "interrupt server >>>>>> task" is not presently blocked in rt_intr_wait for a particular >>>>>> interrupt, how does Xenomai know that a task is actually an >>>>>> "interrupt server task" ? When does this association happen ? Does a >>>>>> call to rt_intr_create make Xenomai log interrupts for the domain >>>>>> from which rt_intr_create was called ? >>>>>> >>>>>> >>>>>> >>>>> This call delivers interrupts to the Xenomai domain, only. >>>>> >>>>> For the rest, have a look at ksrc/skins/native/syscall.c, >>>>> __rt_intr_wait, and >>>>> __rt_intr_handler. >>>>> >>>>> >>>>> >>>>> >>>>>> Thanks ! >>>>>> Tomas >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Xenomai-help mailing list >>>>>> Xenomai-help@domain.hid >>>>>> https://mail.gna.org/listinfo/xenomai-help >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-04-15 17:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-14 0:44 [Xenomai-help] Interrupt propagation question Tomas Kalibera
2008-04-14 7:26 ` Philippe Gerum
2008-04-14 17:14 ` Tomas Kalibera
2008-04-14 20:33 ` Philippe Gerum
[not found] ` <4803D33B.5050507@domain.hid>
[not found] ` <48045AEF.5000005@domain.hid>
2008-04-15 17:08 ` Tomas Kalibera
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.