[Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

[Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

[Klaas Gadeyne]

Hi,

we're having a problem finding a non-shared IRQ for a PEAK systems can
board in a particular industrial SBC with PCI backplane [*].
Loading the xeno_can_peak_pci driver fails due to a "so-called" IRQ
conflict. (see below)

However, it seems the IRQ (12) is not assigned, so this shouldn't be a
problem [**]?

zeus:~# uname -a
Linux zeus 2.6.24-ipipe-2.0-03 #1 PREEMPT Tue Mar 4 14:54:02 CET 2008
            i686 GNU/Linux
zeus:~# cat /proc/interrupts
            CPU0
   0:     527508    XT-PIC-XT        timer
   1:        301    XT-PIC-XT        i8042
   2:          0    XT-PIC-XT        cascade
  10:        770    XT-PIC-XT        eth0
  11:       4386    XT-PIC-XT        libata
  14:       4333    XT-PIC-XT        ide0
  15:          0    XT-PIC-XT        libata
NMI:          0   Non-maskable interrupts
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0
zeus:~# modprobe xeno_can_peak_pci
zeus:~# dmesg | tail
rtcan: registered rtcan0
PEAK-PCI-CAN: base_addr=f8a62400 conf_addr=f88b0000 irq=12
IRQ = 12
ERROR -16: IRQ 12 is busy, check shared interrupt support!
ERROR -16 while trying to register SJA1000 device!
Removing PEAK-PCI SJA1000 device rtcan0
Unregistering SJA1000 device rtcan0
RTCAN: unregistered rtcan0
PEAK-PCI-CAN: probe of 0000:04:06.0 failed with error -16
zeus:~# lspci -vv | tail
         Capabilities: [b0] Slot ID: 0 slots, First-, chassis 00

04:06.0 Network controller: Unknown device 001c:0001 (rev 02)
         Subsystem: Unknown device 001c:0004
         Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
         ParErr- Stepping- SERR- FastB2B-
         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
         >TAbort- <TAbort- <MAbort- >SERR- <PERR-
         Interrupt: pin A routed to IRQ 12
         Region 0: Memory at d0100000 (32-bit, non-prefetchable)
         [size=64K]
         Region 1: Memory at d0110000 (32-bit, non-prefetchable)
         [size=64K]


Any hints on how to debug this?  We've already tried everything
described in the FAQ (I guess), but we don't understand there's a
conflict even if nothing is listed in /proc/interrupts?

Thx,

Klaas

[*] Putting the card in another pc works out just fine.

Re: [Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

[Wolfgang Grandegger]

Klaas Gadeyne wrote:
> Hi,
> 
> we're having a problem finding a non-shared IRQ for a PEAK systems can
> board in a particular industrial SBC with PCI backplane [*].
> Loading the xeno_can_peak_pci driver fails due to a "so-called" IRQ
> conflict. (see below)
> 
> However, it seems the IRQ (12) is not assigned, so this shouldn't be a
> problem [**]?
> 
> zeus:~# uname -a
> Linux zeus 2.6.24-ipipe-2.0-03 #1 PREEMPT Tue Mar 4 14:54:02 CET 2008
>             i686 GNU/Linux
> zeus:~# cat /proc/interrupts
>             CPU0
>    0:     527508    XT-PIC-XT        timer
>    1:        301    XT-PIC-XT        i8042
>    2:          0    XT-PIC-XT        cascade
>   10:        770    XT-PIC-XT        eth0
>   11:       4386    XT-PIC-XT        libata
>   14:       4333    XT-PIC-XT        ide0
>   15:          0    XT-PIC-XT        libata
> NMI:          0   Non-maskable interrupts
> TRM:          0   Thermal event interrupts
> SPU:          0   Spurious interrupts
> ERR:          0
> zeus:~# modprobe xeno_can_peak_pci
> zeus:~# dmesg | tail
> rtcan: registered rtcan0
> PEAK-PCI-CAN: base_addr=f8a62400 conf_addr=f88b0000 irq=12
> IRQ = 12
> ERROR -16: IRQ 12 is busy, check shared interrupt support!
> ERROR -16 while trying to register SJA1000 device!
> Removing PEAK-PCI SJA1000 device rtcan0
> Unregistering SJA1000 device rtcan0
> RTCAN: unregistered rtcan0
> PEAK-PCI-CAN: probe of 0000:04:06.0 failed with error -16
> zeus:~# lspci -vv | tail
>          Capabilities: [b0] Slot ID: 0 slots, First-, chassis 00
> 
> 04:06.0 Network controller: Unknown device 001c:0001 (rev 02)
>          Subsystem: Unknown device 001c:0004
>          Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
>          ParErr- Stepping- SERR- FastB2B-
>          Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>          >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>          Interrupt: pin A routed to IRQ 12
>          Region 0: Memory at d0100000 (32-bit, non-prefetchable)
>          [size=64K]
>          Region 1: Memory at d0110000 (32-bit, non-prefetchable)
>          [size=64K]
> 
> 
> Any hints on how to debug this?  We've already tried everything
> described in the FAQ (I guess), but we don't understand there's a
> conflict even if nothing is listed in /proc/interrupts?

There are two CAN controllers on the card, right? Therefore you need
support for shared interrupts. Actually, requesting the IRQ 12 for the
second CAN controller fails because it's already used by the first one.

Wolfgang-

Re: [Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

[Klaas Gadeyne]

On Wed, 5 Mar 2008, Wolfgang Grandegger wrote:
> Klaas Gadeyne wrote:
>> Hi,
>>
>> we're having a problem finding a non-shared IRQ for a PEAK systems can
>> board in a particular industrial SBC with PCI backplane [*].
>> Loading the xeno_can_peak_pci driver fails due to a "so-called" IRQ
>> conflict. (see below)
>>
>> However, it seems the IRQ (12) is not assigned, so this shouldn't be a
>> problem [**]?

[...]
>> Any hints on how to debug this?  We've already tried everything
>> described in the FAQ (I guess), but we don't understand there's a
>> conflict even if nothing is listed in /proc/interrupts?
>
> There are two CAN controllers on the card, right? Therefore you need
> support for shared interrupts. Actually, requesting the IRQ 12 for the
> second CAN controller fails because it's already used by the first one.

Thx! (we've just found out ourselves that the difference in behaviour
between the 2 pc's was indeed due to different xenomai versions
(<http://svn.gna.org/viewcvs/xenomai?rev=3291&view=rev>).

Klaas

Re: [Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

[Wolfgang Grandegger]

Klaas Gadeyne wrote:
> On Wed, 5 Mar 2008, Wolfgang Grandegger wrote:
>> Klaas Gadeyne wrote:
>>> Hi,
>>>
>>> we're having a problem finding a non-shared IRQ for a PEAK systems can
>>> board in a particular industrial SBC with PCI backplane [*].
>>> Loading the xeno_can_peak_pci driver fails due to a "so-called" IRQ
>>> conflict. (see below)
>>>
>>> However, it seems the IRQ (12) is not assigned, so this shouldn't be a
>>> problem [**]?
> 
> [...]
>>> Any hints on how to debug this?  We've already tried everything
>>> described in the FAQ (I guess), but we don't understand there's a
>>> conflict even if nothing is listed in /proc/interrupts?
>>
>> There are two CAN controllers on the card, right? Therefore you need
>> support for shared interrupts. Actually, requesting the IRQ 12 for the
>> second CAN controller fails because it's already used by the first one.
> 
> Thx! (we've just found out ourselves that the difference in behaviour
> between the 2 pc's was indeed due to different xenomai versions
> (<http://svn.gna.org/viewcvs/xenomai?rev=3291&view=rev>).

Well, yes. Since commit 3291

http://svn.gna.org/viewcvs/xenomai?rev=3291&view=rev

the driver does not tolerate that failure any more. Do you prefer the
old behavior (ignoring the failure and using just the first channel)?

Wolfgang.

Re: [Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

[Klaas Gadeyne]

On Wed, 5 Mar 2008, Wolfgang Grandegger wrote:
> Klaas Gadeyne wrote:
>> On Wed, 5 Mar 2008, Wolfgang Grandegger wrote:
>>> Klaas Gadeyne wrote:
>>>> Hi,
>>>>
>>>> we're having a problem finding a non-shared IRQ for a PEAK systems can
>>>> board in a particular industrial SBC with PCI backplane [*].
>>>> Loading the xeno_can_peak_pci driver fails due to a "so-called" IRQ
>>>> conflict. (see below)
>>>>
>>>> However, it seems the IRQ (12) is not assigned, so this shouldn't be a
>>>> problem [**]?
>>
>> [...]
>>>> Any hints on how to debug this?  We've already tried everything
>>>> described in the FAQ (I guess), but we don't understand there's a
>>>> conflict even if nothing is listed in /proc/interrupts?
>>>
>>> There are two CAN controllers on the card, right? Therefore you need
>>> support for shared interrupts. Actually, requesting the IRQ 12 for the
>>> second CAN controller fails because it's already used by the first one.
>>
>> Thx! (we've just found out ourselves that the difference in behaviour
>> between the 2 pc's was indeed due to different xenomai versions
>> (<http://svn.gna.org/viewcvs/xenomai?rev=3291&view=rev>).
>
> Well, yes. Since commit 3291
>
> http://svn.gna.org/viewcvs/xenomai?rev=3291&view=rev
>
> the driver does not tolerate that failure any more. Do you prefer the
> old behavior (ignoring the failure and using just the first channel)?

Well, it took us quite some time to figure out what was wrong.  But
partly (hold tight, now comes the whole story :-) this was due to the
fact that 
- we ordered a new card recently and were not sure if the problem
   had something to do with the card.
- we already had problems on the SBC using shared interrupts with
   other boards before

So, when we read the error message

<quote>
"busy, check shared interrupt support"
</quote>

we did not think about problems originating to the 2 channels on the board,
and falsely concluded there was a problem sharing a RT and non-RT
interrupt.  Also, we did not install xenomai from source, but from a
package.  Hence, we did not review the kernel config options.

That said, 
1/ I just reviewed the Kconfig file and I think the
documentation is lacking behind

config XENO_DRIVERS_CAN_SJA1000_PEAK_PCI
         depends on XENO_DRIVERS_CAN_SJA1000
         tristate "PEAK PCI Card"
         help

         This driver is for the PCAN PCI, the PC-PCI CAN plug-in card
         (1 or 2 channel) from PEAK Systems (http://www.peak-system.com). To
         get the second channel working, Xenomai's shared interrupt support
         must be enabled.

2/ Maybe the error message could be somewhat more explicit?

Hence something like:

[kgad@domain.hid ~/SVN/xenomai-v2.4.x/ksrc/drivers/can/sja1000]$
  svn diff
Index: Kconfig
===================================================================
--- Kconfig     (revision 3533)
+++ Kconfig     (working copy)
@@ -27,9 +27,9 @@
         help

         This driver is for the PCAN PCI, the PC-PCI CAN plug-in card (1 or 
-       2 channel) from PEAK Systems (http://www.peak-system.com). To
-       get the second channel working, Xenomai's shared interrupt support
-       must be enabled.
+       2 channel) from PEAK Systems (http://www.peak-system.com). If
+       you have a card with 2 channels, Xenomai's shared interrupt
+       support must be enabled or the driver will refuse to load!

  config XENO_DRIVERS_CAN_SJA1000_IXXAT_PCI
         depends on XENO_DRIVERS_CAN_SJA1000
Index: rtcan_sja1000.c
===================================================================
--- rtcan_sja1000.c     (revision 3533)
+++ rtcan_sja1000.c     (working copy)
@@ -765,7 +765,7 @@
      if (ret) {
         printk(KERN_ERR "ERROR %d: IRQ %d is %s!\n",
                ret, chip->irq_num, ret == -EBUSY ?
-              "busy, check shared interrupt support" : "invalid");
+              "busy. If you have a card with > 1 channel, check if CONFIG_XENO_OPT_SHIRQ* is set" : "invalid");
         return ret;
      }

Not kernel coding style, I know :-)

regards,

Klaas

Re: [Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

[Jan Kiszka]

Klaas Gadeyne wrote:
> --- rtcan_sja1000.c     (revision 3533)
> +++ rtcan_sja1000.c     (working copy)
> @@ -765,7 +765,7 @@
>       if (ret) {
>          printk(KERN_ERR "ERROR %d: IRQ %d is %s!\n",
>                 ret, chip->irq_num, ret == -EBUSY ?
> -              "busy, check shared interrupt support" : "invalid");
> +              "busy. If you have a card with > 1 channel, check if CONFIG_XENO_OPT_SHIRQ* is set" : "invalid");
>          return ret;
>       }
> 
> Not kernel coding style, I know :-)

#ifndef CONFIG_XENO_OPT_SHIRQ
	printk("Enable CONFIG_XENO_OPT_SHIRQ")
?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

[Wolfgang Grandegger]

Jan Kiszka wrote:
> Klaas Gadeyne wrote:
>> --- rtcan_sja1000.c     (revision 3533)
>> +++ rtcan_sja1000.c     (working copy)
>> @@ -765,7 +765,7 @@
>>       if (ret) {
>>          printk(KERN_ERR "ERROR %d: IRQ %d is %s!\n",
>>                 ret, chip->irq_num, ret == -EBUSY ?
>> -              "busy, check shared interrupt support" : "invalid");
>> +              "busy. If you have a card with > 1 channel, check if CONFIG_XENO_OPT_SHIRQ* is set" : "invalid");
>>          return ret;
>>       }
>>
>> Not kernel coding style, I know :-)
> 
> #ifndef CONFIG_XENO_OPT_SHIRQ
> 	printk("Enable CONFIG_XENO_OPT_SHIRQ")
> ?

No. In the past the config name changed with 2.4 and that was the main
reason to remove it from the driver. I'm going to update the description
and error messages as suggested by Klaas, but avoiding the config name.

Thanks,

Wolfgang.

Re: [Xenomai-help] Shared IRQ issue with Xeno Peak PCI CAN driver

[Jan Kiszka]

Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Klaas Gadeyne wrote:
>>> --- rtcan_sja1000.c     (revision 3533)
>>> +++ rtcan_sja1000.c     (working copy)
>>> @@ -765,7 +765,7 @@
>>>       if (ret) {
>>>          printk(KERN_ERR "ERROR %d: IRQ %d is %s!\n",
>>>                 ret, chip->irq_num, ret == -EBUSY ?
>>> -              "busy, check shared interrupt support" : "invalid");
>>> +              "busy. If you have a card with > 1 channel, check if CONFIG_XENO_OPT_SHIRQ* is set" : "invalid");
>>>          return ret;
>>>       }
>>>
>>> Not kernel coding style, I know :-)
>> #ifndef CONFIG_XENO_OPT_SHIRQ
>> 	printk("Enable CONFIG_XENO_OPT_SHIRQ")
>> ?
> 
> No. In the past the config name changed with 2.4 and that was the main
> reason to remove it from the driver. I'm going to update the description
> and error messages as suggested by Klaas, but avoiding the config name.

Ok, that makes sense. I was thinking, if there is alreay
CONFIG_XENO_OPT_SHIRQ in the text, we could also make it depend on that
switch. If there is no explicit mentioning, even better.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux