Re: usb interrupt conflict with RTAI

What you said is right.

The sharing of IRQs between RTAI and Linux should not be a choice if strict determinism is required.

If it cannot be avoided one should try, if possible:
- change the slot of a conflicting card;
- check if it is possible to force the IRQ number using BIOS;
- do not install the conflicting Linux driver (you suggestion)  or try to make available an free interrupt by disabling other, unused, Linux drivers.

If none works and you have a local APIC you should try, with the same board and CPU, ugrading Linux and RTAI and enable the local APIC and IO_APIC, along with MSI.

A further solution, which is not granted to workP is to serve the conflincting Linux iterrupt through a light virtualized virtual environment, e.g. UML just serving such an interrupt.

Paolo.
________________________________________
From: Dietrich Pescoller [[email protected]]
Sent: Tuesday, August 29, 2017 9:50 AM
To: Paolo Mantegazza
Cc: Dietrich Pescoller; [email protected]
Subject: Re: [Rtai] usb interrupt conflict with RTAI

After further test we noticed the following:
the system "basically" works, in the sense it is not stopping anymore with the
*** RTDM: xnintr_irq_handler: IRQ11 not handled. Disabling IRQ line. ***
message.

However the problem we see now is that the performance is quite poor. I was
expecting that the additional interrupt of the usb stick would not degrade to
much the performance since the interrupt handling would take just a couple of
hundreds (perhaps) of NANOseconds in the Real Time space, the rest of the
handling would be delegated to the non real time linux kernel.
This was my first expectation.

However from the performance observation/experimentation I believe we have a
"jitter" in the order of the hundreds of MICROseconds.

This was little bit surprising me, and after some thoughts my explanation for
this is the following:
It is true that the USB interrupt is handled by the NON-Realtime Kernel task,
BUT, until the interrupt is not handled the interrupt (irq#11) remains
disabled, thus delaying the income of other NIC interrupts.

I think this is exactly what you were mentioning with

"""The problem, depending on edge-level interrupts, may come from interrupt
enabling on the side of the two colliding interrupts.""",
isn't it?

My feeling is that it is NOT possible to share interrupts between Real Time
and Linux Kernel without affecting performance. (hundreds of nanoseconds
additional jitter would be acceptable of course). Is this correct?

Please consider that any hardware reconfiguration, is quite difficult. Right
now...

So perhaps the only solution seems to be to access the USB stick only when the
system is not in Active mode, i.e. the NIC is not operating and we can accept
big jitters on the NIC.

Many thanks,
for your feedback
Dietrich



On Wednesday 23 August 2017 19:59:39 Paolo Mantegazza wrote:
> If it works it will likely stay so. The problem, depending on edge-level
> interrupts, may come from interrupt enabling on the side of the two
> colliding interrupts. To be sure it is OK you have just to wait the
> completion of your validation phase. Since you are on a old hardware, is it
> possible that the ether card is a true card and not integrated in the
> motherboard chipset? In such a case it might be possible avoiding an
> interrupt collision by changing the ether card slot. Instead, if the ether
> support is integrated you can still mute it and, provided you have free
> slots, install another ether card. Since you are on an  XT-PIC I do not see
> other alternatives. It seems you understood what "I (you) have not well
> understood". Sorry for not rereading what I wrote.
>
> Paolo.
> ________________________________________
> From: Dietrich Pescoller [[email protected]]
> Sent: Wednesday, August 23, 2017 6:50 PM
> To: Paolo Mantegazza
> Cc: Dietrich Pescoller; [email protected]
> Subject: Re: [Rtai] usb interrupt conflict with RTAI
>
> Hi Paolo,
> thanks for the feedback.
> The system is a production system (ALMA Telescope)
> so upgrading is really not an option unfortunately. (at least for now).
>
> Digging into the RT-Net code meanwhile I found that in e1000_main.c (the
> driver I'm using for my NIC) is not propagating interrupts he don't owns.
>
> i.e. in the interrupt service routine I changed the following code:
>       if (unlikely(!icr)) {
>         return RTDM_IRQ_NONE;  /* Not our interrupt */
>         }
> to
>         if (unlikely(!icr)) {
>         return XN_ISR_PROPAGATE;  /* Not our interrupt */
>         }
> So in other words I use the feature you described.
> This solved the issue. Now we are testing and validating. I hope there are
> no bad side-effects surprises.
>
>
> I have not well understood what you mean with "... , but
> just int he case they know its kind and what is it for..."""
>
> Do you thing the change I did to the driver is kind of hazard?
>
> Thanks
> Dietrich
>
> On Wednesday 23 August 2017 16:06:36 Paolo Mantegazza wrote:
> > RTAI, and so RTDM,  can pend (pass) an interrupt they use down to Linux,
> > but jjust int he case they know its kind and what is it for. In Clearly
> > in your case it is not so, In your case I see that you are using very old
> > versions for both RTAI and Linux. My suggestion is to upgrade both and
> > see what happens.By way of example, if your hartdware is not really
> > really old it is possible that using the APIC under UP coupled to MSI
> > support could solve the problem, without caring of anything else.
> >
> > Paolo
> > ________________________________________
> > From: Rtai [[email protected]] on behalf of Dietrich Pescoller
> > [[email protected]] Sent: Tuesday, August 22, 2017 11:40 AM
> > To: [email protected]
> > Subject: [Rtai] usb interrupt conflict with RTAI
> >
> > Dear all,
> >
> > I'm facing an issue with shared interrupts
> >
> > The problem I have is that i wanted to integrate a USB-stick for storage,
> > but my USB system is conflicting with the RTAI system.
> >
> > As soon as I load the usb-storage.ko module I get the following message
> > from the
> >
> > kernel:
> >         RTDM: xnintr_irq_handler: IRQ11 not handled. Disabling IRQ line.
> >
> > After this message the system system stops working, i.e. no RT ethernet
> > packets are received anymore.
> >
> > My setup is quite old and is as follow:
> > - Linux Kernel 2.6.19.7
> > - rtai-3.6
> > - rtnet-0.9.11
> >
> > looking at /proc/interrupts
> > ====
> >
> >   0:     108824    XT-PIC-XT        timer, rtai_broadcast
> >   1:          8    XT-PIC-XT        i8042
> >   2:          0    XT-PIC-XT        cascade
> >   4:          0    XT-PIC-XT        tpmc901drv
> >   7:       2392    XT-PIC-XT        eth0
> >   9:          0     XT-PIC-XT        uhci_hcd:usb2
> >
> >  11:         28   XT-PIC-XT        uhci_hcd:usb1  <--- conflicting
> >  interrupt
> >
> > 12:          3    XT-PIC-XT        i8042
> >
> >  14:          0    XT-PIC-XT        libata
> >  15:       1773    XT-PIC-XT        libata
> >
> > NMI:          1
> > LOC:     108794
> > ERR:          0
> > MIS:          0
> >
> > and /proc/rtai/hal
> > ====
> >
> > ** Real-time IRQs used by RTAI:
> >     #3 at e00ab290
> >     #4 at e00e3279
> >     #11 at e3b85420    <--- conflicting interrupt
> >     #215 at e00cbb80
> >     #216 at e00cb2d0
> >
> > I see that the irq #11 is shared between an Ethernet NIC and the USB, and
> > something is not handled properly. The Ethernet NIC is in handled by a
> > RTNET driver i.e. e1000.ko.
> >
> > I searched for a possibility to remap this interrupt in the BIOS of my
> > board but unfortunately there seems to be no option for that.
> >
> > I see here the following possible solutions but I did not found a way
> > manage them (I'm still blocked in the teory...)
> >
> > 1) try to understand why the shared interrupt #11 is not forwarded to
> > linux, is probably a rtnet e1000 driver issue... avoiding RTDM to disable
> > the IRQ line.
> > 2) remap the interrupt by software, I don't know if this is possible...
> >
> > Many thanks in advance for your help/advices
> >
> > Bye,
> > Dietrich
> > _______________________________________________
> > Rtai mailing list
> > [email protected]
> > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai

_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai