Kernel-2.6.15 does not respond interrupt from my PCI card

wenjia ganganwen at gmail.com
Fri Jul 7 05:58:59 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 think it must be written in the data sheet.
>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.
I am not familiar with APIC,but there is a note from RTAI3.3 user manual maybe useful:
Note: Attention must be taken for the APIC (Advanced Programmable Interrupt Controller)
configuration; the option is located under Processor type and features. In the previous
versions the APIC had to be disabled on UP machine, and could only by used on MP ones. With
the latest RTAI release the APIC can be enabled and used with success even on UP machines
and with this option enabled the system will benefit of faster timer reprogramming in oneshot
mode and lesser overhead. 
>
>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 
>clashing.
>
>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
>
>IO-APIC-level
>
>and others as
>
>IO-APIC-edge
>
>do you know from where this difference comes from?
>
>Rodrigo
>
>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 roe.ac.uk 
>> 
>>> -----Original Message-----
>>> From: Rodrigo Amestica [mailto:ramestic at nrao.edu] 
>>> Sent: 05 July 2006 18:22
>>> To: Xiaofeng Gao
>>> Cc: rtai at rtai.org; 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