Re: usb interrupt conflict with RTAI

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