Re: usb interrupt conflict with RTAI

Thanks,
I have now a clearer picture.

Dietrich

On Tuesday 29 August 2017 10:46:00 Paolo Mantegazza wrote:
> 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