[Xenomai-help] Kernel lockup when shared IRQ is enabled

[Xenomai-help] Kernel lockup when shared IRQ is enabled

[Steven Kauffmann]

Hi all,

As some other people on this mailing list, we also have system lockups
with the latest 2.4 branch. For some people the problems seems to be
solved when using the adeos-ipipe-2.6.28.9-x86-2.2-07.patch. So we
tried that but the system still freezes. The console output on another
machine reports nothing when the system freezes but at computer
startup we found this line:

Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.

lspci shows us that the peak CAN card and the ethernet controller use
the same IRQ.

$ lspci -v

02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet
Controller
        Subsystem: Intel Corporation Unknown device 0000
        Flags: bus master, fast devsel, latency 0, IRQ 11
        Memory at d0000000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at c000 [size=32]
        Capabilities: <access denied>

04:05.0 Network controller: Unknown device 001c:0001 (rev 02)
        Subsystem: Unknown device 001c:0004
        Flags: medium devsel, IRQ 11
        Memory at d0100000 (32-bit, non-prefetchable) [size=64K]
        Memory at d0110000 (32-bit, non-prefetchable) [size=64K]

Every time we try to bring up the ethernet device the system freezes.
Is this related with the above kernel log message and that both cards
use the same IRQ?

Disabling the shared IRQ option (XENO_OPT_SHIRQ) solved the problem of
the system lockups but this option is required in order to use the
peak CAN card.


Regards

Steven

Re: [Xenomai-help] Kernel lockup when shared IRQ is enabled

[Sebastian Smolorz]

Steven Kauffmann wrote:
> Hi all,
>
> As some other people on this mailing list, we also have system lockups
> with the latest 2.4 branch. For some people the problems seems to be
> solved when using the adeos-ipipe-2.6.28.9-x86-2.2-07.patch. So we
> tried that but the system still freezes. The console output on another
> machine reports nothing when the system freezes but at computer
> startup we found this line:
>
> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.
>
> lspci shows us that the peak CAN card and the ethernet controller use
> the same IRQ.

Generally, it is problematic to share IRQs between RT and NRT devices. You 
better try to decouple these two devices WRT IRQ sharing.

> Every time we try to bring up the ethernet device the system freezes.
> Is this related with the above kernel log message and that both cards
> use the same IRQ?

Are you sure that the system freezes? Do you happen to be logged in over the 
net?

-- 
Sebastian

Re: [Xenomai-help] Kernel lockup when shared IRQ is enabled

[Steven Kauffmann]

2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
> Steven Kauffmann wrote:
>> Hi all,
>>
>> As some other people on this mailing list, we also have system lockups
>> with the latest 2.4 branch. For some people the problems seems to be
>> solved when using the adeos-ipipe-2.6.28.9-x86-2.2-07.patch. So we
>> tried that but the system still freezes. The console output on another
>> machine reports nothing when the system freezes but at computer
>> startup we found this line:
>>
>> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.
>>
>> lspci shows us that the peak CAN card and the ethernet controller use
>> the same IRQ.
>
> Generally, it is problematic to share IRQs between RT and NRT devices. You
> better try to decouple these two devices WRT IRQ sharing.
>
>> Every time we try to bring up the ethernet device the system freezes.
>> Is this related with the above kernel log message and that both cards
>> use the same IRQ?
>
> Are you sure that the system freezes? Do you happen to be logged in over the
> net?

Yes I'm sure. I cannot ping to the system anymore ...

Re: [Xenomai-help] Kernel lockup when shared IRQ is enabled

[Sebastian Smolorz]

Steven Kauffmann wrote:
> 2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
> > Steven Kauffmann wrote:
> >> Hi all,
> >>
> >> As some other people on this mailing list, we also have system lockups
> >> with the latest 2.4 branch. For some people the problems seems to be
> >> solved when using the adeos-ipipe-2.6.28.9-x86-2.2-07.patch. So we
> >> tried that but the system still freezes. The console output on another
> >> machine reports nothing when the system freezes but at computer
> >> startup we found this line:
> >>
> >> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.
> >>
> >> lspci shows us that the peak CAN card and the ethernet controller use
> >> the same IRQ.
> >
> > Generally, it is problematic to share IRQs between RT and NRT devices.
> > You better try to decouple these two devices WRT IRQ sharing.
> >
> >> Every time we try to bring up the ethernet device the system freezes.
> >> Is this related with the above kernel log message and that both cards
> >> use the same IRQ?
> >
> > Are you sure that the system freezes? Do you happen to be logged in over
> > the net?
>
> Yes I'm sure. I cannot ping to the system anymore ...

That is not a sign of a freezed system. The ping does not get replied because 
the ethernet IRQ is not handled any more. I bet the system continues to work. 
You can check this by using a serial console or a local keyboard.

-- 
Sebastian

Re: [Xenomai-help] Kernel lockup when shared IRQ is enabled

[Philippe Gerum]

On Mon, 2009-05-04 at 15:39 +0200, Sebastian Smolorz wrote:
> Steven Kauffmann wrote:
> > 2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
> > > Steven Kauffmann wrote:
> > >> Hi all,
> > >>
> > >> As some other people on this mailing list, we also have system lockups
> > >> with the latest 2.4 branch. For some people the problems seems to be
> > >> solved when using the adeos-ipipe-2.6.28.9-x86-2.2-07.patch. So we
> > >> tried that but the system still freezes. The console output on another
> > >> machine reports nothing when the system freezes but at computer
> > >> startup we found this line:
> > >>
> > >> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.
> > >>
> > >> lspci shows us that the peak CAN card and the ethernet controller use
> > >> the same IRQ.
> > >
> > > Generally, it is problematic to share IRQs between RT and NRT devices.
> > > You better try to decouple these two devices WRT IRQ sharing.
> > >
> > >> Every time we try to bring up the ethernet device the system freezes.
> > >> Is this related with the above kernel log message and that both cards
> > >> use the same IRQ?
> > >
> > > Are you sure that the system freezes? Do you happen to be logged in over
> > > the net?
> >
> > Yes I'm sure. I cannot ping to the system anymore ...
> 
> That is not a sign of a freezed system. The ping does not get replied because 
> the ethernet IRQ is not handled any more. I bet the system continues to work. 
> You can check this by using a serial console or a local keyboard.

Maybe an interrupt storm kills the board as soon as interrupts are
enabled again in case the ethernet IRQ is level sensitive, since the
last event was not handled.

-- 
Philippe.

Re: [Xenomai-help] Kernel lockup when shared IRQ is enabled

[Steven Kauffmann]

2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
> Steven Kauffmann wrote:
>> 2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
>> > Steven Kauffmann wrote:
>> >> Hi all,
>> >>
>> >> As some other people on this mailing list, we also have system lockups
>> >> with the latest 2.4 branch. For some people the problems seems to be
>> >> solved when using the adeos-ipipe-2.6.28.9-x86-2.2-07.patch. So we
>> >> tried that but the system still freezes. The console output on another
>> >> machine reports nothing when the system freezes but at computer
>> >> startup we found this line:
>> >>
>> >> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.
>> >>
>> >> lspci shows us that the peak CAN card and the ethernet controller use
>> >> the same IRQ.
>> >
>> > Generally, it is problematic to share IRQs between RT and NRT devices.
>> > You better try to decouple these two devices WRT IRQ sharing.
>> >
>> >> Every time we try to bring up the ethernet device the system freezes.
>> >> Is this related with the above kernel log message and that both cards
>> >> use the same IRQ?
>> >
>> > Are you sure that the system freezes? Do you happen to be logged in over
>> > the net?
>>
>> Yes I'm sure. I cannot ping to the system anymore ...
>
> That is not a sign of a freezed system. The ping does not get replied because
> the ethernet IRQ is not handled any more. I bet the system continues to work.
> You can check this by using a serial console or a local keyboard.

The system doesn't react when I try to switch to the first virtual terminal.

Re: [Xenomai-help] Kernel lockup when shared IRQ is enabled

[Gilles Chanteperdrix]

Steven Kauffmann wrote:
> 2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
>> Steven Kauffmann wrote:
>>> 2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
>>>> Steven Kauffmann wrote:
>>>>> Hi all,
>>>>>
>>>>> As some other people on this mailing list, we also have system lockups
>>>>> with the latest 2.4 branch. For some people the problems seems to be
>>>>> solved when using the adeos-ipipe-2.6.28.9-x86-2.2-07.patch. So we
>>>>> tried that but the system still freezes. The console output on another
>>>>> machine reports nothing when the system freezes but at computer
>>>>> startup we found this line:
>>>>>
>>>>> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.
>>>>>
>>>>> lspci shows us that the peak CAN card and the ethernet controller use
>>>>> the same IRQ.
>>>> Generally, it is problematic to share IRQs between RT and NRT devices.
>>>> You better try to decouple these two devices WRT IRQ sharing.
>>>>
>>>>> Every time we try to bring up the ethernet device the system freezes.
>>>>> Is this related with the above kernel log message and that both cards
>>>>> use the same IRQ?
>>>> Are you sure that the system freezes? Do you happen to be logged in over
>>>> the net?
>>> Yes I'm sure. I cannot ping to the system anymore ...
>> That is not a sign of a freezed system. The ping does not get replied because
>> the ethernet IRQ is not handled any more. I bet the system continues to work.
>> You can check this by using a serial console or a local keyboard.
> 
> The system doesn't react when I try to switch to the first virtual terminal.

The sharing of IRQs between real-time and non real-time hardware is in
fact an FAQ: "What can I do if Xenomai and Linux devices share the same
IRQ?"

http://www.xenomai.org/index.php/FAQs

The lockup you get could come from this first problem. So, you should
eliminate this problem before concluding that Xenomai has a bug on your
hardware.

-- 
                                                 Gilles.

Re: [Xenomai-help] Kernel lockup when shared IRQ is enabled

[Steven Kauffmann]

On Tue, May 5, 2009 at 9:48 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Steven Kauffmann wrote:
>> 2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
>>> Steven Kauffmann wrote:
>>>> 2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
>>>>> Steven Kauffmann wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> As some other people on this mailing list, we also have system lockups
>>>>>> with the latest 2.4 branch. For some people the problems seems to be
>>>>>> solved when using the adeos-ipipe-2.6.28.9-x86-2.2-07.patch. So we
>>>>>> tried that but the system still freezes. The console output on another
>>>>>> machine reports nothing when the system freezes but at computer
>>>>>> startup we found this line:
>>>>>>
>>>>>> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.
>>>>>>
>>>>>> lspci shows us that the peak CAN card and the ethernet controller use
>>>>>> the same IRQ.
>>>>> Generally, it is problematic to share IRQs between RT and NRT devices.
>>>>> You better try to decouple these two devices WRT IRQ sharing.
>>>>>
>>>>>> Every time we try to bring up the ethernet device the system freezes.
>>>>>> Is this related with the above kernel log message and that both cards
>>>>>> use the same IRQ?
>>>>> Are you sure that the system freezes? Do you happen to be logged in over
>>>>> the net?
>>>> Yes I'm sure. I cannot ping to the system anymore ...
>>> That is not a sign of a freezed system. The ping does not get replied because
>>> the ethernet IRQ is not handled any more. I bet the system continues to work.
>>> You can check this by using a serial console or a local keyboard.
>>
>> The system doesn't react when I try to switch to the first virtual terminal.
>
> The sharing of IRQs between real-time and non real-time hardware is in
> fact an FAQ: "What can I do if Xenomai and Linux devices share the same
> IRQ?"
>
> http://www.xenomai.org/index.php/FAQs
>
> The lockup you get could come from this first problem. So, you should
> eliminate this problem before concluding that Xenomai has a bug on your
> hardware.

What I didn't mention in my previous mails is that I can trigger the
lockup of my system by starting eclipse.

I tried to get a unique IRQ for the CAN card, but it looks like it
always shares it IRQ with another device (USB controller or VGA
controller or ... ). At the moment it shares the IRQ (IRQ 10) with the
VGA controller but the system runs fine now (I can start eclipse). Why
can it share the IRQ with the VGA controller without having the lockup
or is it just good luck?

I also tried it on another patched kernel (2.6.27.19-ipipe-2.2-06) and
now my CAN card gets another IRQ (IRQ 16) and again shares it with the
VGA controller. Are the kernel options CONFIG_X86_LOCAL_APIC and
CONFIG_X86_IO_APIC responsible for the differences of the IRQ between
the two kernels?

But if I try to open eclipse in this kernel my system freezes again.
Even if I unplug the CAN card (the only PCI card in my system) the
system freezes when I try to start eclipse.

Re: [Xenomai-help] Kernel lockup when shared IRQ is enabled

[Gilles Chanteperdrix]

Steven Kauffmann wrote:
> On Tue, May 5, 2009 at 9:48 AM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> Steven Kauffmann wrote:
>>> 2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
>>>> Steven Kauffmann wrote:
>>>>> 2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
>>>>>> Steven Kauffmann wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> As some other people on this mailing list, we also have system lockups
>>>>>>> with the latest 2.4 branch. For some people the problems seems to be
>>>>>>> solved when using the adeos-ipipe-2.6.28.9-x86-2.2-07.patch. So we
>>>>>>> tried that but the system still freezes. The console output on another
>>>>>>> machine reports nothing when the system freezes but at computer
>>>>>>> startup we found this line:
>>>>>>>
>>>>>>> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.
>>>>>>>
>>>>>>> lspci shows us that the peak CAN card and the ethernet controller use
>>>>>>> the same IRQ.
>>>>>> Generally, it is problematic to share IRQs between RT and NRT devices.
>>>>>> You better try to decouple these two devices WRT IRQ sharing.
>>>>>>
>>>>>>> Every time we try to bring up the ethernet device the system freezes.
>>>>>>> Is this related with the above kernel log message and that both cards
>>>>>>> use the same IRQ?
>>>>>> Are you sure that the system freezes? Do you happen to be logged in over
>>>>>> the net?
>>>>> Yes I'm sure. I cannot ping to the system anymore ...
>>>> That is not a sign of a freezed system. The ping does not get replied because
>>>> the ethernet IRQ is not handled any more. I bet the system continues to work.
>>>> You can check this by using a serial console or a local keyboard.
>>> The system doesn't react when I try to switch to the first virtual terminal.
>> The sharing of IRQs between real-time and non real-time hardware is in
>> fact an FAQ: "What can I do if Xenomai and Linux devices share the same
>> IRQ?"
>>
>> http://www.xenomai.org/index.php/FAQs
>>
>> The lockup you get could come from this first problem. So, you should
>> eliminate this problem before concluding that Xenomai has a bug on your
>> hardware.
> 
> What I didn't mention in my previous mails is that I can trigger the
> lockup of my system by starting eclipse.
> 
> I tried to get a unique IRQ for the CAN card, but it looks like it
> always shares it IRQ with another device (USB controller or VGA
> controller or ... ). At the moment it shares the IRQ (IRQ 10) with the
> VGA controller but the system runs fine now (I can start eclipse). Why
> can it share the IRQ with the VGA controller without having the lockup
> or is it just good luck?

Even when it works, sharing should be avoided because it destroys
determinism. To make it work without destroying determinism, you have to
modify the drivers code. There is no way around.

> 
> I also tried it on another patched kernel (2.6.27.19-ipipe-2.2-06) and
> now my CAN card gets another IRQ (IRQ 16) and again shares it with the
> VGA controller. Are the kernel options CONFIG_X86_LOCAL_APIC and
> CONFIG_X86_IO_APIC responsible for the differences of the IRQ between
> the two kernels?

Yes, using the local APIC and IO-APIC change the irq numbers.

> 
> But if I try to open eclipse in this kernel my system freezes again.
> Even if I unplug the CAN card (the only PCI card in my system) the
> system freezes when I try to start eclipse.

This is probably unrelated. Try to get the console output on serial
port, or if not possible on netconsole.

-- 
                                                 Gilles.

Re: [Xenomai-help] Kernel lockup when shared IRQ is enabled

[Martin Shepherd]

On Tue, 5 May 2009, Steven Kauffmann wrote:
> I tried to get a unique IRQ for the CAN card, but it looks like it
> always shares it IRQ with another device (USB controller or VGA
> controller or ... ).

Note that there are often two flavors of USB driver loaded, one being
uhci_hcd and the other ehci_hcd. The uhci_hcd driver handles USB 1.1
devices, and on my systems it seems to use up one IRQ per USB
port. The ehci_hcd driver only seems to need one IRQ. So if you can
get away with just USB2.0 support, then you can probably free up a few
IRQs by not running the uhci_hcd driver, while leaving the EHCI driver
in place for USB2.0 devices.

> Yes, using the local APIC and IO-APIC change the irq numbers.

Indeed. With regards to this, beware that the IRQ number that the
"lspci -vv" command reports for a given PCI device, is generally wrong
until the PCI device is enabled via a call to pci_enable_device().
Before being enabled, lspci reports the value of the interrupt-line
configuration register of the PCI device, whereas after the device is
enabled, lspci reports the value that the PCI BIOS actually assigned
to the device. So be sure to use the IRQ that pertains after enabling
the device, to determine whether or not you have an IRQ conflict.

Martin

Re: [Xenomai-help] Kernel lockup when shared IRQ is enabled

[Steven Kauffmann]

On Tue, May 5, 2009 at 2:26 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Steven Kauffmann wrote:
>> On Tue, May 5, 2009 at 9:48 AM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> Steven Kauffmann wrote:
>>>> 2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
>>>>> Steven Kauffmann wrote:
>>>>>> 2009/5/4 Sebastian Smolorz <smolorz@domain.hid>:
>>>>>>> Steven Kauffmann wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> As some other people on this mailing list, we also have system lockups
>>>>>>>> with the latest 2.4 branch. For some people the problems seems to be
>>>>>>>> solved when using the adeos-ipipe-2.6.28.9-x86-2.2-07.patch. So we
>>>>>>>> tried that but the system still freezes. The console output on another
>>>>>>>> machine reports nothing when the system freezes but at computer
>>>>>>>> startup we found this line:
>>>>>>>>
>>>>>>>> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.
>>>>>>>>
>>>>>>>> lspci shows us that the peak CAN card and the ethernet controller use
>>>>>>>> the same IRQ.
>>>>>>> Generally, it is problematic to share IRQs between RT and NRT devices.
>>>>>>> You better try to decouple these two devices WRT IRQ sharing.
>>>>>>>
>>>>>>>> Every time we try to bring up the ethernet device the system freezes.
>>>>>>>> Is this related with the above kernel log message and that both cards
>>>>>>>> use the same IRQ?
>>>>>>> Are you sure that the system freezes? Do you happen to be logged in over
>>>>>>> the net?
>>>>>> Yes I'm sure. I cannot ping to the system anymore ...
>>>>> That is not a sign of a freezed system. The ping does not get replied because
>>>>> the ethernet IRQ is not handled any more. I bet the system continues to work.
>>>>> You can check this by using a serial console or a local keyboard.
>>>> The system doesn't react when I try to switch to the first virtual terminal.
>>> The sharing of IRQs between real-time and non real-time hardware is in
>>> fact an FAQ: "What can I do if Xenomai and Linux devices share the same
>>> IRQ?"
>>>
>>> http://www.xenomai.org/index.php/FAQs
>>>
>>> The lockup you get could come from this first problem. So, you should
>>> eliminate this problem before concluding that Xenomai has a bug on your
>>> hardware.
>>
>> What I didn't mention in my previous mails is that I can trigger the
>> lockup of my system by starting eclipse.
>>
>> I tried to get a unique IRQ for the CAN card, but it looks like it
>> always shares it IRQ with another device (USB controller or VGA
>> controller or ... ). At the moment it shares the IRQ (IRQ 10) with the
>> VGA controller but the system runs fine now (I can start eclipse). Why
>> can it share the IRQ with the VGA controller without having the lockup
>> or is it just good luck?
>
> Even when it works, sharing should be avoided because it destroys
> determinism. To make it work without destroying determinism, you have to
> modify the drivers code. There is no way around.
>
>>
>> I also tried it on another patched kernel (2.6.27.19-ipipe-2.2-06) and
>> now my CAN card gets another IRQ (IRQ 16) and again shares it with the
>> VGA controller. Are the kernel options CONFIG_X86_LOCAL_APIC and
>> CONFIG_X86_IO_APIC responsible for the differences of the IRQ between
>> the two kernels?
>
> Yes, using the local APIC and IO-APIC change the irq numbers.

I have two kernels both with the option local APIC and IO-APIC enabled
but the PCI card gets another IRQ assigned if I change the kernel. Is
this normal or are other kernel options responsible for this behavior?

>>
>> But if I try to open eclipse in this kernel my system freezes again.
>> Even if I unplug the CAN card (the only PCI card in my system) the
>> system freezes when I try to start eclipse.
>
> This is probably unrelated. Try to get the console output on serial
> port, or if not possible on netconsole.

At the moment the systems freezes I do not get any output. Do I have
to enable some extra kernel debug options?

Re: [Xenomai-help] Kernel lockup when shared IRQ is enabled

[Philippe Gerum]

On Mon, 2009-05-04 at 13:59 +0200, Steven Kauffmann wrote:
> Hi all,
> 
> As some other people on this mailing list, we also have system lockups
> with the latest 2.4 branch. For some people the problems seems to be
> solved when using the adeos-ipipe-2.6.28.9-x86-2.2-07.patch.

The issue you are facing has nothing to do with the discussion and fix
mentioned above.

>  So we
> tried that but the system still freezes. The console output on another
> machine reports nothing when the system freezes but at computer
> startup we found this line:
> 
> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.
> 
> lspci shows us that the peak CAN card and the ethernet controller use
> the same IRQ.
> 
> $ lspci -v
> 
> 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet
> Controller
>         Subsystem: Intel Corporation Unknown device 0000
>         Flags: bus master, fast devsel, latency 0, IRQ 11
>         Memory at d0000000 (32-bit, non-prefetchable) [size=128K]
>         I/O ports at c000 [size=32]
>         Capabilities: <access denied>
> 
> 04:05.0 Network controller: Unknown device 001c:0001 (rev 02)
>         Subsystem: Unknown device 001c:0004
>         Flags: medium devsel, IRQ 11
>         Memory at d0100000 (32-bit, non-prefetchable) [size=64K]
>         Memory at d0110000 (32-bit, non-prefetchable) [size=64K]
> 
> Every time we try to bring up the ethernet device the system freezes.
> Is this related with the above kernel log message and that both cards
> use the same IRQ?
> 

Yes. Don't share RT and non-RT (i.e. plain Linux handled) interrupts.
This is a major design flaw.

> Disabling the shared IRQ option (XENO_OPT_SHIRQ) solved the problem of
> the system lockups but this option is required in order to use the
> peak CAN card.

XENO_OPT_SHIRQ is only there to share a single interrupt channel between
multiple RT sources, and _not_ to enable RT and non-RT interrupt sources
to share a single IRQ. Again, that will _never_ work properly with
respect to latency issues. The lockup you see is caused by the Xenomai
RT handler starving the Linux ethernet IRQ handler from interrupts; this
is expected. Working around this is possible, but will not solve the
latency issue, introduced by the initial design flaw.

> 
> 
> Regards
> 
> Steven
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.