Kernel-2.6.15 does not respond interrupt from my PCI card

Rodrigo Amestica ramestic at
Thu Jul 6 18:07:33 CEST 2006

Hi Xiaofeng and Wenjia,

in relation with my PCI parallel port: my problem is that from the data sheet of 
the board I cannot tell how to inform the board that I'm clearing the interrupt. 
The ACK pin is being driven by an external box that generates a square signal 
which I'm trying to follow. Therefore, I cannot take the ACK pin OFF. For the 
'standard' PC parallel port (the one embedded in the mother-board itself) you 
actually need to do _nothing_. It just happens that the ISR is executed only at 
the rising edge (or falling edge, not fully sure) of the signal connected to the 
ACK pin. Perhaps, I need to read the data sheet again..., but my feeling is that 
I'm trying to squeeze orange juice from an apple tree.

Now about APIC and IRQs (this will get a bit too long but I hope it can produce 
some useful information): we have also a data acquisition PCI board that 
requires some attention in what respects its irq. In a dual athlon machine and 
booting _with_ APIC the device is reported by linux at irq 145 
(/sys/devices/.../irq), which is okay. If I boot _without_ APIC then the device 
is reported at irq 5, which is okay as well. No other devices are reported at 
those irqs in both situations.

145 seems to be something decided by the APIC layer, somehow. And 5 seems to be 
something hard wired in the PCI board itself. Fine.

But in a dual opteron machine things go a bit differently. If I boot _without_ 
APIC then the device is reported at irq 5, in the same way it happens for the 
opteron. Now if I boot _with_ APIC then the irq is reported as zero! Not good, 
this is the timer irq and I understand that this allocation hints an interrupt 

This could be of interest: in the driver I have coded a check for irq=0. If that 
happens then I write 5 into the PCI_INTERRUPT_LINE register of the PCI 
configuration area for this device. Then I use 5 when requesting and enabling 
the interrupt (rt_request_global_irq, rt_enable_irq) and, well, things work just 
fine. In any other case (irq!=0) I leave PCI_INTERRUPT_LINE as it is and use its 
content for requesting and enabling the interrupt.

I suppose that this behavioral difference between the athlon and opteron relates 
with the chipset of their respective mother-boards. The athlon has an AMD 
chipset and the opteron has an nVidia chipset. Which should also explain why is 
that the timer interrupt for the opteron remains as XT-PIC even when I'm booting 
_with_ APIC! In the web I found some reference to this artifact and there is 
actually a kernel parameter that tries to fix the issue 
(acpi_skip_timer_override) but I have ACPI disabled for these kernels.

I will finish all this with a new question. When I boot _with_ APIC in 
/proc/interrupts I see some interrupts reported as


and others as


do you know from where this difference comes from?


Xiaofeng Gao wrote:
> Hi, Rodrigo
> Thanks. I thinks I understand the general reason behind the IRQ sharing,
> Since I use the PCI card as part of data acquisition system, during data
> taking, I don't want any other device to generate the same IRQ to trig
> my ISR  and ruin the data taking task. I am just frustrated for not
> being able to get around this. In VxWorks, I can choose IRQ for my card.
> As more and more developers are moving away from vxWorks/VME to
> RTAI/Linux/PC, it will be good that developers can have their choice of
> IRQ for developing data acquisition system without sharing its IRQ.
> Any way, thanks for Wenjia's suggestion. I can avoid this now.   
>> Now I have a question for you, your interrupt handler is now 
>> working. Are you using the APIC? I mean, how does your 
>> /proc/interrupts look like  (APIC or XT)?
> As Wenjia said, I don't have APIC in my kernel config ( I wonder why?),
> I have ACPI which is disabled in kernel config.
> {
> xg at sc3jac ~>cat /proc/interrupts
>            CPU0
>   0:   17940485          XT-PIC  timer, rtai_broadcast
>   1:       4151          XT-PIC  i8042
>   2:          0          XT-PIC  cascade
>   8:          1          XT-PIC  rtc
>  10:          0          XT-PIC  ehci_hcd:usb1, uhci_hcd:usb2
>  11:     530553          XT-PIC  libata, uhci_hcd:usb3, uhci_hcd:usb4,
> uhci_hcd:usb5, eth0
>  12:     206736          XT-PIC  i8042
>  14:     643010          XT-PIC  ide0
> NMI:          0
> LOC:   17940442
> ERR:          4
> MIS:          0
> }
> I do notice, however, that over some period ( this time it is over
> night), there were some strange things happening, though it did not harm
> my ISR.  my PC has PCI express and SATA HDD. See dmesg
> {
> ...
> spurious 8259A interrupt: IRQ15.
> hda: cdrom_pc_intr: The drive appears confused (ireason = 0x01)
> hda: cdrom_pc_intr: The drive appears confused (ireason = 0x01)
> hda: cdrom_pc_intr: The drive appears confused (ireason = 0x01)
> xg at sc3jac ~>                                                         
> }
> By the way, I have not seen any of those problems I mentioned when I use
> kernel-2.4.20/RTAI-24.1.3 on other PC.
>> In the source code for sc2pcicardHandler there is a line that says:
>> // Read off the message words and do things
>> Does this include something like an interrupt acknowledgment 
>> for the board? Sometimes reading a register will do it.
> Yes,  My PCI card has a Motorola DSP56301 to handler all messages on PCI
> bus. If my ISR is trigged, it knows there are some things in HRXS
> register on the DSP, it acknowledgments PCI card by sending a special
> word to the DSP and reads out all messages from the register.
>> The interrupt happens in the expected irq but it keeps on 
>> interrupting as long as the ACK pin is ON. As a level 
>> interrupt that I do not understand how to acknowledge in 
>> order to clear the interrupt to happen again until the next 
>> rising or falling edge of the input signal.
> I don't know exactly what your design is.  My first thought is as soon
> as your ISR is trigged, disable the interrupt immediately, then send a
> command to your board to take ACK pin as "OFF". Before finishing your
> ISR, re-enable irq.
> i.e.
> void sc2pcicardHandler
> (
> void
> )
> {
>    rt_disable_irq(dev->irq); 
>    rt_printk("%ld pci_handler>  ISR starts \n", msgcnt++);
>    // ask PCI board to take ACK pin "OFF"
>    // Read off the message words and do things
>   {
>      ....
>   }
>   rt_enable_irq(dev->irq);
>   return;   // ISR completes 
> } 
> Hope this helps.
> Cheers
> Xiaofeng Gao              xg at 
>> -----Original Message-----
>> From: Rodrigo Amestica [mailto:ramestic at] 
>> Sent: 05 July 2006 18:22
>> To: Xiaofeng Gao
>> Cc: rtai at; Rodrigo Amestica
>> Subject: Re: Kernel-2.6.15 does not respond interrupt from my PCI card
>> Hi,
>> unfortunately I cannot tell how to check for a 'free' IRQ. I 
>> have the impression that the pci_ API has some functions that 
>> will let you check what are the already assigned irqs, but 
>> with this you can not assume that no body else will use your 
>> same irq in the future. I mean, after your driver is loaded 
>> some other driver could be loaded and it could happily share 
>> your same irq. It seems that for PCI devices you must assume 
>> that your IRQ would be  eventually shared, and do something about it.

More information about the Rtai mailing list