[Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.

[Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.

[Dennis Nguyen]

Hello,

I'm using linux kernel 2.6.22.12, xenomai 2.4-rc6, and rtnet trunk 1140
date 11/15/2007. There are 2 8139 RealTek nics in the system 

I got the disable IRQ messages when loading RTnet modules:
Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.
Xenomai: xnintr_shirq_handler: IRQ10 not handled. Disable IRQ line.

one nic using IRQ 11 and the other using IRQ 10
These cause the rteth0 and rteth1 not receive any packages.

How can I enable the interrupts? or control so that the
xnintr_shirq_handler not disable the interrupts?

Thanks in advance.
Dennis  

[Xenomai-help] can't bringing up eth0

[indra sakti]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

Hello,...

I'm trying to install xenomai-2.4-rc5 with vanilla kernel 2.6.23... I use my old working config file, and disable power management option. I compile my kernel and  xenomai, following the tutorial in www.captain.at .. Everything is ok, until i reboot and choose my new kernel with xenomai. In the startup service, it's always fail in bringing up interface eth0. If i choose NO to start that service, then my linux can continue working.

Can anyone tell me how to solve my problem?

Thanx for any answer or suggestion..:)


==================
Indra Sakti Wijayanto
sakti7387@domain.hid
==================

       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.

[-- Attachment #2: Type: text/html, Size: 810 bytes --]

Re: [Xenomai-help] can't bringing up eth0

[Leopold Palomo-Avellaneda]

A Dimecres 21 Novembre 2007, indra sakti va escriure:
> Hello,...
>
> I'm trying to install xenomai-2.4-rc5 with vanilla kernel 2.6.23... I use
> my old working config file, and disable power management option. I compile
> my kernel and  xenomai, following the tutorial in www.captain.at ..
> Everything is ok, until i reboot and choose my new kernel with xenomai. In
> the startup service, it's always fail in bringing up interface eth0. If i
> choose NO to start that service, then my linux can continue working.
>
> Can anyone tell me how to solve my problem?
>
> Thanx for any answer or suggestion..:)

look the udev rules because changing the kernel maybe the new kernel put 
another name to your network card as eth1 or eth2 ... I have been crazy with 
this kind of problems and after are simple a different name.

Regards,

Leo

Re: [Xenomai-help] can't bringing up eth0

[Gilles Chanteperdrix]

On Nov 21, 2007 2:24 AM, indra sakti <sakti7387@domain.hid> wrote:
> Hello,...
>
> I'm trying to install xenomai-2.4-rc5 with vanilla kernel 2.6.23... I use my
> old working config file, and disable power management option. I compile my
> kernel and  xenomai, following the tutorial in www.captain.at .. Everything
> is ok, until i reboot and choose my new kernel with xenomai. In the startup
> service, it's always fail in bringing up interface eth0. If i choose NO to
> start that service, then my linux can continue working.
>
> Can anyone tell me how to solve my problem?
>
> Thanx for any answer or suggestion..:)

Could you post your kernel logs ?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.

[Gilles Chanteperdrix]

On Nov 20, 2007 11:42 PM, Dennis Nguyen <dennisnguy@domain.hid> wrote:
> Hello,
>
> I'm using linux kernel 2.6.22.12, xenomai 2.4-rc6, and rtnet trunk 1140
> date 11/15/2007. There are 2 8139 RealTek nics in the system
>
> I got the disable IRQ messages when loading RTnet modules:
> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.
> Xenomai: xnintr_shirq_handler: IRQ10 not handled. Disable IRQ line.
>
> one nic using IRQ 11 and the other using IRQ 10
> These cause the rteth0 and rteth1 not receive any packages.
>
> How can I enable the interrupts? or control so that the
> xnintr_shirq_handler not disable the interrupts?

There are several reasons why this can happen. One reason is a bug in
the drivers interrupt handler, which returns RTDM_IRQ_NONE whereas it
should not. Another reason is that the IRQs 10 and 11 are shared
between the ethernet driver and non real-time drivers. This can not
work.


-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.

[DENNIS NGUYEN]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

Hello Gilles,

Thanks for the advice.
Yes, I have problem with sharing the IRQ 11.
my questions are:
How can I set the rteth0 to a known not sharing IRQ in the system?
How can I pass a known IRQ from RTnet to the Xenomai xnintr_shirq_handler?
I tried to fix the IRQ from "network configuration" but it didn't help.  I also tried to set up the system BIOS but it did not have IRQ configuration.
The Realtek NICs are using PCI bus.

Thanks,
Dennis



Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: On Nov 20, 2007 11:42 PM, Dennis Nguyen  wrote:
> Hello,
>
> I'm using linux kernel 2.6.22.12, xenomai 2.4-rc6, and rtnet trunk 1140
> date 11/15/2007. There are 2 8139 RealTek nics in the system
>
> I got the disable IRQ messages when loading RTnet modules:
> Xenomai: xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.
> Xenomai: xnintr_shirq_handler: IRQ10 not handled. Disable IRQ line.
>
> one nic using IRQ 11 and the other using IRQ 10
> These cause the rteth0 and rteth1 not receive any packages.
>
> How can I enable the interrupts? or control so that the
> xnintr_shirq_handler not disable the interrupts?

There are several reasons why this can happen. One reason is a bug in
the drivers interrupt handler, which returns RTDM_IRQ_NONE whereas it
should not. Another reason is that the IRQs 10 and 11 are shared
between the ethernet driver and non real-time drivers. This can not
work.


-- 
                                               Gilles Chanteperdrix


[-- Attachment #2: Type: text/html, Size: 1855 bytes --]

Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.

[Jeroen Van den Keybus]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

>
> Yes, I have problem with sharing the IRQ 11.
> my questions are:
> How can I set the rteth0 to a known not sharing IRQ in the system?


- You already said you don't have BIOS options.
- If you have multiple PCI slots, try swapping the cards. Usually, adjacent
slots have different interrupt lines. But you might end up sharing with
something else.
- Avoid the use of the sharing device (possible with audio, some USB, ...)
- Check if ACPI configures the interrupt lines for you (bypassing the BIOS).
I don't know for sure, but I think you can use the acpi_irq_pci kernel
parameter to somehow influence the mapping of the physical interrupt lines
to logical IRQ lines (numbers).
- You could also try to share the same IRQ for both cards (again by
replacing them in the PCI slots).

But, in all fairness, I think your problem lies elsewhere, because both
IRQ10 and 11 are affected and disabling only occurs after a lot (1000 or so)
of unhandled requests have happened.



> How can I pass a known IRQ from RTnet to the Xenomai xnintr_shirq_handler?


The PCI interrupts are fixed after BIOS (or ACPI) has done its job. If you
change the number of the IRQ line by moving it or using the BIOS/ACPI,
it should also change correctly.


What does the dmesg log say ? Perhaps you can turn on debugging for the
rtnet driver and get more info.

Last but not least: do the cards work correctly in parallel using the
standard Linux driver (8139too) ?


Jeroen.

[-- Attachment #2: Type: text/html, Size: 2007 bytes --]

Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.

[Dennis Nguyen]

Hi Jeroen,

Thanks for the information.

The Xenomai disabled the interrupt when it saw the sharing. The message 
log from dmesg was:
xenomai: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.

The NICs worked normally with 8139too.ko and 8139cp.ko drivers.

I have three difference types of PCs: pentium III 650 Mhz, Core2, and 
AMD athlon 2Ghz. on different mother boards.  All of them have conflict 
IRQs with xenomai and RTnet.  I swapped the slots but it did not 
changed.  I'm thinking of giving the NICs  fixed IRQ but I don't know how.

Anyone have any ideas?

Thanks,
Dennis



Jeroen Van den Keybus wrote:
>
>     Yes, I have problem with sharing the IRQ 11.
>     my questions are:
>     How can I set the rteth0 to a known not sharing IRQ in the system? 
>
>  
> - You already said you don't have BIOS options.
> - If you have multiple PCI slots, try swapping the cards. Usually, 
> adjacent slots have different interrupt lines. But you might end up 
> sharing with something else.
> - Avoid the use of the sharing device (possible with audio, some USB, ...)
> - Check if ACPI configures the interrupt lines for you (bypassing the 
> BIOS). I don't know for sure, but I think you can use the acpi_irq_pci 
> kernel parameter to somehow influence the mapping of the 
> physical interrupt lines to logical IRQ lines (numbers).
> - You could also try to share the same IRQ for both cards (again by 
> replacing them in the PCI slots).
>  
> But, in all fairness, I think your problem lies elsewhere, because 
> both IRQ10 and 11 are affected and disabling only occurs after a lot 
> (1000 or so) of unhandled requests have happened.
>
>  
>
>     How can I pass a known IRQ from RTnet to the Xenomai
>     xnintr_shirq_handler?
>
>  
> The PCI interrupts are fixed after BIOS (or ACPI) has done its job. If 
> you change the number of the IRQ line by moving it or using the 
> BIOS/ACPI, it should also change correctly.
>  
>  
> What does the dmesg log say ? Perhaps you can turn on debugging for 
> the rtnet driver and get more info.
>  
> Last but not least: do the cards work correctly in parallel using the 
> standard Linux driver (8139too) ?
>  
>  
> Jeroen.

Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.

[Jeroen Van den Keybus]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

>
> The Xenomai disabled the interrupt when it saw the sharing.


I may have mislooked, but doesn't xnintr_shirq_handler only disable the line
after XNINTR_MAX_UNHANDLED problematic IRQs (which is by default set to
1000) ? If you get the error immediately after loading the driver, it looks
like either the interrupt doesn't get properly acknowledged in the I-pipe
(after which the driver gets pounded by 999 stray interrupts, causing it to
return 'unhandled') or the driver fails to acknowledge it on the card.


> The NICs worked normally with 8139too.ko and 8139cp.ko drivers.


Ok. I think that means that at least no weird things happen in the I-pipe or
that the cards are defective (or poorly inserted in slot).


> I have three difference types of PCs: pentium III 650 Mhz, Core2, and
> AMD athlon 2Ghz. on different mother boards.  All of them have conflict
> IRQs with xenomai and RTnet.  I swapped the slots but it did not
> changed.  I'm thinking of giving the NICs  fixed IRQ but I don't know how.


As said before, you can only practically do that in the BIOS or using ACPI.

Does the rtnet driver work correctly with only one card ?


Jeroen.

[-- Attachment #2: Type: text/html, Size: 1815 bytes --]

Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.

[Dennis Nguyen]

Most of the times the RTnet/Xenomai disabled the IRQ right away. few 
time it ran for a while.
It doesn't matter the system has single or 2 cards, it still have 
conflict IRQ.  I tried to change the slot but it did not help.
Thanks,
Dennis

Jeroen Van den Keybus wrote:
>
>     The Xenomai disabled the interrupt when it saw the sharing.
>
>  
> I may have mislooked, but doesn't xnintr_shirq_handler only disable 
> the line after XNINTR_MAX_UNHANDLED problematic IRQs (which is by 
> default set to 1000) ? If you get the error immediately after loading 
> the driver, it looks like either the interrupt doesn't get properly 
> acknowledged in the I-pipe (after which the driver gets pounded by 999 
> stray interrupts, causing it to return 'unhandled') or the driver 
> fails to acknowledge it on the card.
>  
>
>     The NICs worked normally with 8139too.ko and 8139cp.ko drivers.
>
>  
> Ok. I think that means that at least no weird things happen in the 
> I-pipe or that the cards are defective (or poorly inserted in slot).
>  
>
>     I have three difference types of PCs: pentium III 650 Mhz, Core2, and
>     AMD athlon 2Ghz. on different mother boards.  All of them have
>     conflict
>     IRQs with xenomai and RTnet.  I swapped the slots but it did not
>     changed.  I'm thinking of giving the NICs  fixed IRQ but I don't
>     know how.
>
>  
> As said before, you can only practically do that in the BIOS or using 
> ACPI.
>  
> Does the rtnet driver work correctly with only one card ?
>  
>  
> Jeroen.
>  

Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.

[Roland Tollenaar]

post the output of

lspci -v

Roland

Dennis Nguyen wrote:
> Most of the times the RTnet/Xenomai disabled the IRQ right away. few 
> time it ran for a while.
> It doesn't matter the system has single or 2 cards, it still have 
> conflict IRQ.  I tried to change the slot but it did not help.
> Thanks,
> Dennis
> 
> Jeroen Van den Keybus wrote:
>>     The Xenomai disabled the interrupt when it saw the sharing.
>>
>>  
>> I may have mislooked, but doesn't xnintr_shirq_handler only disable 
>> the line after XNINTR_MAX_UNHANDLED problematic IRQs (which is by 
>> default set to 1000) ? If you get the error immediately after loading 
>> the driver, it looks like either the interrupt doesn't get properly 
>> acknowledged in the I-pipe (after which the driver gets pounded by 999 
>> stray interrupts, causing it to return 'unhandled') or the driver 
>> fails to acknowledge it on the card.
>>  
>>
>>     The NICs worked normally with 8139too.ko and 8139cp.ko drivers.
>>
>>  
>> Ok. I think that means that at least no weird things happen in the 
>> I-pipe or that the cards are defective (or poorly inserted in slot).
>>  
>>
>>     I have three difference types of PCs: pentium III 650 Mhz, Core2, and
>>     AMD athlon 2Ghz. on different mother boards.  All of them have
>>     conflict
>>     IRQs with xenomai and RTnet.  I swapped the slots but it did not
>>     changed.  I'm thinking of giving the NICs  fixed IRQ but I don't
>>     know how.
>>
>>  
>> As said before, you can only practically do that in the BIOS or using 
>> ACPI.
>>  
>> Does the rtnet driver work correctly with only one card ?
>>  
>>  
>> Jeroen.
>>  
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 

Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disable IRQ line.

[Jeroen Van den Keybus]

[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]

>
> post the output of
>
> lspci -v


And while you're at it, please also show the results of

cat /proc/interrupts
cat /proc/xenomai/irq

both just before loading the driver and right after the 'Disabling IRQ.'
message.


Jeroen.






> Roland
>
> Dennis Nguyen wrote:
> > Most of the times the RTnet/Xenomai disabled the IRQ right away. few
> > time it ran for a while.
> > It doesn't matter the system has single or 2 cards, it still have
> > conflict IRQ.  I tried to change the slot but it did not help.
> > Thanks,
> > Dennis
> >
> > Jeroen Van den Keybus wrote:
> >>     The Xenomai disabled the interrupt when it saw the sharing.
> >>
> >>
> >> I may have mislooked, but doesn't xnintr_shirq_handler only disable
> >> the line after XNINTR_MAX_UNHANDLED problematic IRQs (which is by
> >> default set to 1000) ? If you get the error immediately after loading
> >> the driver, it looks like either the interrupt doesn't get properly
> >> acknowledged in the I-pipe (after which the driver gets pounded by 999
> >> stray interrupts, causing it to return 'unhandled') or the driver
> >> fails to acknowledge it on the card.
> >>
> >>
> >>     The NICs worked normally with 8139too.ko and 8139cp.ko drivers.
> >>
> >>
> >> Ok. I think that means that at least no weird things happen in the
> >> I-pipe or that the cards are defective (or poorly inserted in slot).
> >>
> >>
> >>     I have three difference types of PCs: pentium III 650 Mhz, Core2,
> and
> >>     AMD athlon 2Ghz. on different mother boards.  All of them have
> >>     conflict
> >>     IRQs with xenomai and RTnet.  I swapped the slots but it did not
> >>     changed.  I'm thinking of giving the NICs  fixed IRQ but I don't
> >>     know how.
> >>
> >>
> >> As said before, you can only practically do that in the BIOS or using
> >> ACPI.
> >>
> >> Does the rtnet driver work correctly with only one card ?
> >>
> >>
> >> Jeroen.
> >>
> >
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> >
>
>

[-- Attachment #2: Type: text/html, Size: 3188 bytes --]

Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.

[Dennis Nguyen]

Jeroen, Roland,

I'm sorry for replying late.  my interrupt conflicts could be solved by 
using only one NIC or upgrade to Linux 2.6.23.9.  Interestingly I 
noticed that the kernel 2.6.23.9 assigned different IRQ for each PCI device.
My solution is using Linux i386 2.6.23.9 and xenomai 2.4-rc7.
Thanks for your help,
Dennis

Jeroen Van den Keybus wrote:
>
>     post the output of
>
>     lspci -v
>
>  
> And while you're at it, please also show the results of
>  
> cat /proc/interrupts
> cat /proc/xenomai/irq
>  
> both just before loading the driver and right after the 'Disabling 
> IRQ.' message.
>  
>  
> Jeroen.
>  
>
>  
>
>
>  
>
>     Roland
>
>     Dennis Nguyen wrote:
>     > Most of the times the RTnet/Xenomai disabled the IRQ right away.
>     few
>     > time it ran for a while.
>     > It doesn't matter the system has single or 2 cards, it still have
>     > conflict IRQ.  I tried to change the slot but it did not help.
>     > Thanks,
>     > Dennis
>     >
>     > Jeroen Van den Keybus wrote:
>     >>     The Xenomai disabled the interrupt when it saw the sharing.
>     >>
>     >>
>     >> I may have mislooked, but doesn't xnintr_shirq_handler only
>     disable
>     >> the line after XNINTR_MAX_UNHANDLED problematic IRQs (which is by
>     >> default set to 1000) ? If you get the error immediately after
>     loading
>     >> the driver, it looks like either the interrupt doesn't get
>     properly
>     >> acknowledged in the I-pipe (after which the driver gets pounded
>     by 999
>     >> stray interrupts, causing it to return 'unhandled') or the driver
>     >> fails to acknowledge it on the card.
>     >>
>     >>
>     >>     The NICs worked normally with 8139too.ko and 8139cp.ko drivers.
>     >>
>     >>
>     >> Ok. I think that means that at least no weird things happen in the
>     >> I-pipe or that the cards are defective (or poorly inserted in
>     slot).
>     >>
>     >>
>     >>     I have three difference types of PCs: pentium III 650 Mhz,
>     Core2, and
>     >>     AMD athlon 2Ghz. on different mother boards.  All of them have
>     >>     conflict
>     >>     IRQs with xenomai and RTnet.  I swapped the slots but it
>     did not
>     >>     changed.  I'm thinking of giving the NICs  fixed IRQ but I
>     don't
>     >>     know how.
>     >>
>     >>
>     >> As said before, you can only practically do that in the BIOS or
>     using
>     >> ACPI.
>     >>
>     >> Does the rtnet driver work correctly with only one card ?
>     >>
>     >>
>     >> Jeroen.
>     >>
>     >
>     > _______________________________________________
>     > Xenomai-help mailing list
>     > Xenomai-help@domain.hid <mailto:Xenomai-help@domain.hid>
>     > https://mail.gna.org/listinfo/xenomai-help
>     >
>
>

Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line.

[Jeroen Van den Keybus]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

>
> I'm sorry for replying late.  my interrupt conflicts could be solved by
> using only one NIC or upgrade to Linux 2.6.23.9.  Interestingly I
> noticed that the kernel 2.6.23.9 assigned different IRQ for each PCI
> device.


That's exactly what I meant by trying to have ACPI reorganize the interrupts
for you. Never compile without CONFIG_ACPI=yes... And beware, I believe that
the IRQ config may vary, theoretically even upon every reboot.

Jeroen.

[-- Attachment #2: Type: text/html, Size: 756 bytes --]

Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ line

[Dennis Nguyen]

Jeroem,

You right, 
set CONFIG_ACPI=y
and turn off PCI BIOS
#CONFIG_PCI_BIOS is not set
The kernel will assign unique IRQ for each PCI device.

Thanks,
Dennis

On Fri, 2007-11-30 at 12:01 +0100, xenomai-help-request@domain.hid wrote:
> Send Xenomai-help mailing list submissions to
> 	xenomai@xenomai.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://mail.gna.org/listinfo/xenomai-help
> or, via email, send a message with subject or body 'help' to
> 	xenomai-help-request@domain.hid
> 
> You can reach the person managing the list at
> 	xenomai-help-owner@domain.hid
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Xenomai-help digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: xnintr_shirq_handler: IRQ11 not handled. Disabling IRQ
>       line. (Dennis Nguyen)
>    2. rt_queue_write strange behaviour (Roderik.Wildenburg@domain.hid)
>    3. Re: xnintr_shirq_handler: IRQ11 not handled.	Disabling IRQ
>       line. (Jeroen Van den Keybus)
>    4. rt_queue_write strange behaviour ++
>       (Roderik.Wildenburg@domain.hid)
>    5. error while rt_task_wait_period, code -110 (Andreas Vogt)
>    6. Re: rt_queue_write strange behaviour ++ (Philippe Gerum)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 29 Nov 2007 06:52:19 -0800
> From: Dennis Nguyen <dennisnguy@domain.hid>
> Subject: Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled.
> 	Disabling IRQ line.
> To: Jeroen Van den Keybus <jeroen.vandenkeybus@domain.hid>,
> 	rolandtollenaar@domain.hid
> Cc: xenomai@xenomai.org
> Message-ID: <474ED223.9040009@domain.hid>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Jeroen, Roland,
> 
> I'm sorry for replying late.  my interrupt conflicts could be solved by 
> using only one NIC or upgrade to Linux 2.6.23.9.  Interestingly I 
> noticed that the kernel 2.6.23.9 assigned different IRQ for each PCI device.
> My solution is using Linux i386 2.6.23.9 and xenomai 2.4-rc7.
> Thanks for your help,
> Dennis
> 
> Jeroen Van den Keybus wrote:
> >
> >     post the output of
> >
> >     lspci -v
> >
> >  
> > And while you're at it, please also show the results of
> >  
> > cat /proc/interrupts
> > cat /proc/xenomai/irq
> >  
> > both just before loading the driver and right after the 'Disabling 
> > IRQ.' message.
> >  
> >  
> > Jeroen.
> >  
> >
> >  
> >
> >
> >  
> >
> >     Roland
> >
> >     Dennis Nguyen wrote:
> >     > Most of the times the RTnet/Xenomai disabled the IRQ right away.
> >     few
> >     > time it ran for a while.
> >     > It doesn't matter the system has single or 2 cards, it still have
> >     > conflict IRQ.  I tried to change the slot but it did not help.
> >     > Thanks,
> >     > Dennis
> >     >
> >     > Jeroen Van den Keybus wrote:
> >     >>     The Xenomai disabled the interrupt when it saw the sharing.
> >     >>
> >     >>
> >     >> I may have mislooked, but doesn't xnintr_shirq_handler only
> >     disable
> >     >> the line after XNINTR_MAX_UNHANDLED problematic IRQs (which is by
> >     >> default set to 1000) ? If you get the error immediately after
> >     loading
> >     >> the driver, it looks like either the interrupt doesn't get
> >     properly
> >     >> acknowledged in the I-pipe (after which the driver gets pounded
> >     by 999
> >     >> stray interrupts, causing it to return 'unhandled') or the driver
> >     >> fails to acknowledge it on the card.
> >     >>
> >     >>
> >     >>     The NICs worked normally with 8139too.ko and 8139cp.ko drivers.
> >     >>
> >     >>
> >     >> Ok. I think that means that at least no weird things happen in the
> >     >> I-pipe or that the cards are defective (or poorly inserted in
> >     slot).
> >     >>
> >     >>
> >     >>     I have three difference types of PCs: pentium III 650 Mhz,
> >     Core2, and
> >     >>     AMD athlon 2Ghz. on different mother boards.  All of them have
> >     >>     conflict
> >     >>     IRQs with xenomai and RTnet.  I swapped the slots but it
> >     did not
> >     >>     changed.  I'm thinking of giving the NICs  fixed IRQ but I
> >     don't
> >     >>     know how.
> >     >>
> >     >>
> >     >> As said before, you can only practically do that in the BIOS or
> >     using
> >     >> ACPI.
> >     >>
> >     >> Does the rtnet driver work correctly with only one card ?
> >     >>
> >     >>
> >     >> Jeroen.
> >     >>
> >     >
> >     > _______________________________________________
> >     > Xenomai-help mailing list
> >     > Xenomai-help@domain.hid <mailto:Xenomai-help@domain.hid>
> >     > https://mail.gna.org/listinfo/xenomai-help
> >     >
> >
> >
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 29 Nov 2007 16:05:43 +0100
> From: <Roderik.Wildenburg@domain.hid>
> Subject: [Xenomai-help] rt_queue_write strange behaviour
> To: <xenomai@xenomai.org>
> Message-ID:
> 	<5D63919D95F87E4D9D34FF7748CE2C2AE3C474@domain.hid>
> Content-Type: text/plain; charset="us-ascii"
> 
> Sometimes we get an EINVAL-Error with rt_queue_write.
> If we immediatelly after the EINVAL-Error try an a second time to write
> to the queue (with exactly the same parameters as at the first time) the
> rt_queue_write succeeds (see appended code sniped) !!??
> 
> I traced down (xnprintf) the error to the function rt_queue_send where a
> plausibility test is made :
> 
> if (xnheap_check_block(&q->bufpool, msg) || msg->refcount == 0) 
> [approx at line 614]
> 
> this test fail as (msg->refcount == 0).
> If I understand the comment correctly :
> 
> /* In case of invalid block or if the sender does not own the
>    message, just bail out. */
> 
> the sender does not own the message.
> But if so, the second try should fail also (and I am quite sure the
> message belongs to the sender) ?
> Does anyone (probabliy Philipe) has an idea in what situation this
> problem could occur or what is the reason for this stange behaviour ?
> 
> Unfortunately I could not reproduce this problem in a simple testcase.
> Therefore I do not have an simple test case, but with our application
> the error occurs regularly (~10 times a hour).
> So I rely on your intuition to spike this problem.
> 
> Many thanks in advance and best regards
> Roderik 
> 
> MAN Roland Druckmaschinen AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle    
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592    
> USt-Ident-Nr. DE 250200933
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: rt_queue_write.c
> Type: application/octet-stream
> Size: 815 bytes
> Desc: rt_queue_write.c
> Url : /public/xenomai-help/attachments/20071129/49757763/attachment.obj 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 29 Nov 2007 17:50:58 +0100
> From: "Jeroen Van den Keybus" <jeroen.vandenkeybus@domain.hid>
> Subject: Re: [Xenomai-help] xnintr_shirq_handler: IRQ11 not handled.
> 	Disabling IRQ line.
> To: "Dennis Nguyen" <dennisnguy@domain.hid>
> Cc: xenomai@xenomai.org
> Message-ID:
> 	<fd6a47a90711290850w5d21c703na1af5eab5eee928c@domain.hid>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> >
> > I'm sorry for replying late.  my interrupt conflicts could be solved by
> > using only one NIC or upgrade to Linux 2.6.23.9.  Interestingly I
> > noticed that the kernel 2.6.23.9 assigned different IRQ for each PCI
> > device.
> 
> 
> That's exactly what I meant by trying to have ACPI reorganize the interrupts
> for you. Never compile without CONFIG_ACPI=yes... And beware, I believe that
> the IRQ config may vary, theoretically even upon every reboot.
> 
> Jeroen.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: /public/xenomai-help/attachments/20071129/77b71f7b/attachment.htm 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 30 Nov 2007 11:42:57 +0100
> From: <Roderik.Wildenburg@domain.hid>
> Subject: [Xenomai-help] rt_queue_write strange behaviour ++
> To: <xenomai@xenomai.org>
> Message-ID:
> 	<5D63919D95F87E4D9D34FF7748CE2C2AE3C69D@ARVMAIL1.mra.roland-man.biz>
> Content-Type: text/plain;	charset="iso-8859-1"
> 
> Sorry, but in my last mail (see below) I had forgotten to tell you my 
> Xenomai-Version and architecture.
> I still use Xenomai 2.3.2 on PPC.
> 
> In the meantime I had a deeper look into the Xenomai source code 
> and I would say, the case we observed (msg->refcount == 0 ; see below)
> isn?t possible with rt_queue_write, as this function implicitly allocate 
> its messagebuffer and rt_queue_alloc initilaizes refcount to 1.
> Immediatelly after this rt_queue_send is called, where the 
> plausibility test if( msg->refcount == 0) is done and fails. 
> So, I can?t see a gap where refcount falls back to 0.
> 
> Does any guru have a good idea, I am quite clueless.
> 
> Original mail :
> --------------------------------------------------------------------
> 
> Sometimes we get an EINVAL-Error with rt_queue_write.
> If we immediatelly after the EINVAL-Error try an a second time to write
> to the queue (with exactly the same parameters as at the first time) the
> rt_queue_write succeeds (see appended code sniped) !!??
> 
> I traced down (xnprintf) the error to the function rt_queue_send where a
> plausibility test is made :
> 
> if (xnheap_check_block(&q->bufpool, msg) || msg->refcount == 0) 
> [approx at line 614]
> 
> this test fail as (msg->refcount == 0).
> If I understand the comment correctly :
> 
> /* In case of invalid block or if the sender does not own the
>    message, just bail out. */
> 
> the sender does not own the message.
> But if so, the second try should fail also (and I am quite sure the
> message belongs to the sender) ?
> Does anyone (probabliy Philipe) has an idea in what situation this
> problem could occur or what is the reason for this strange behaviour ?
> 
> Unfortunately I could not reproduce this problem in a simple testcase, 
> but with our application the error occurs regularly (~10 times a hour).
> So I rely on your intuition to spike this problem.
> 
> Many thanks in advance and best regards
> Roderik 
> 
> MAN Roland Druckmaschinen AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle    
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592    
> USt-Ident-Nr. DE 250200933
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Fri, 30 Nov 2007 11:52:48 +0100
> From: Andreas Vogt <A_C_V@web.de>
> Subject: [Xenomai-help] error while rt_task_wait_period, code -110
> To: xenomai@xenomai.org
> Message-ID: <1829866571@domain.hid>
> Content-Type: text/plain; charset="iso-8859-15"
> 
> Hallo,
> 
> I get an error in a simple program with a period time of 1 ms.My latency test program works with a period of 100us.The worst latenz time is about 23us
> Any suggestions?
> 
> Andreas
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: speaker.c
> Type: text/x-csrc
> Size: 2030 bytes
> Desc: not available
> Url : /public/xenomai-help/attachments/20071130/5061d2c3/attachment.c 
> 
> ------------------------------
> 
> Message: 6
> Date: Fri, 30 Nov 2007 11:55:20 +0100
> From: Philippe Gerum <rpm@xenomai.org>
> Subject: Re: [Xenomai-help] rt_queue_write strange behaviour ++
> To: Roderik.Wildenburg@domain.hid
> Cc: xenomai@xenomai.org
> Message-ID: <474FEC18.7040304@domain.hid>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Roderik.Wildenburg@domain.hid wrote:
> > Sorry, but in my last mail (see below) I had forgotten to tell you my 
> > Xenomai-Version and architecture.
> > I still use Xenomai 2.3.2 on PPC.
> > 
> > In the meantime I had a deeper look into the Xenomai source code 
> > and I would say, the case we observed (msg->refcount == 0 ; see below)
> > isn?t possible with rt_queue_write, as this function implicitly allocate 
> > its messagebuffer and rt_queue_alloc initilaizes refcount to 1.
> > Immediatelly after this rt_queue_send is called, where the 
> > plausibility test if( msg->refcount == 0) is done and fails. 
> > So, I can?t see a gap where refcount falls back to 0.
> 
> Does the attached patch trigger any message when your app fails?
>