Hi Jan, the problem was that the previous interrupt was not correctly served (IIR was not read). UART still reported the new interrupt in its IIR register, but probably did not send the INTR signal to the PIC.
Cheers, Tomas Jan Kiszka wrote: > Tomas Kalibera wrote: >> Hi Jan, >>> Try to pass I_EDGE to rt_intr_create. The UART IRQs are edge-triggered, >>> so you have to enable the appropriate handling at kernel IRQ handler >>> level. >>> >>> Jan >>> >> >> I'm calling rt_intr_create from user space, so I cannot specify >> I_EDGE. But even if I could, looking at the code I assumed that >> I_EDGE was only applicable together with I_SHARED, and should be only >> used when I need to share and edge IRQ among multiple rt_intr >> objects/interrupt handlers. Is that correct ? > > Yeah, that was nonsense. It's a shared-IRQ thing, and those won't work > via the native API anyway. > > If you can identify a point when something interesting just happened > (which means much less than 10 seconds ago), try placing a > xntrace_user_freeze() at that location and use the I-pipe tracer to > analyse the history of the system (of the last few milliseconds). That > can help to understand what does or does not go on at lower levels. > Find more infos on the tracer in the wiki. > > BTW, there is also a test case available for IRQ delivery via > null-modem, check irqbench. It doesn't use the rt_intr API, but the > same hardware. > > Jan > _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
