Where is the interrupt going?

* Where is the interrupt going?
@ 2007-11-22  1:08 Al Niessner
  2007-11-22  1:56 ` Alan Cox
                   ` (4 more replies)
  0 siblings, 5 replies; 17+ messages in thread
From: Al Niessner @ 2007-11-22  1:08 UTC (permalink / raw)
  To: linux-kernel

Quickly stated, I have a piece of hardware on the PCI bus that is
generating an interrupt (can watch it with a scope) but my handler is
not being called (no printk in /var/log/messages). So, where has the
interrupt gone?

Obligatory information:
1) I have done the google search and mailing list search finding lots of
ancillary information but not what I needed.
2) Yes, it is my fault, but I need some help from people more directly
involved in the kernel than myself to point out what I am doing wrong.
3) Thanks for any and all help in advance.

On with the detailed technical information. I developed a kernel module
for an PCI card back in 2.4, moved it to 2.6.3, then 2.6.11 or so and
now I am trying to move it to 2.6.22. When I began the to move to
2.6.22, I changed all of the deprecated calls for finding the card on
the PCI bus, modified the interrupt handler prototype, and changed my
readvv/writev to aio_read/aio_write following
http://lwn.net/Articles/202449/. So initialization looks like this:

p8620 = pci_get_device (APC8620_VENDOR_ID, APC8620_DEVICE_ID, p8620);
<... fail if p8620 is 0 ...>
apcsi[i].ret_val = register_chrdev (MAJOR_NUM,

DEVICE_NAME,

&apc8620_ops);
<... fail if ret_val < 0 ...>
apcsi[i].board_irq = p8620->irq;
status = request_irq (apcsi[i].board_irq,
                                      apc8620_handler,
                                      IRQF_DISABLED,
                                      DEVICE_NAME,
                                      (void*)&apcsi[i]);
<... fail if status != 0 ...>

I do check all of the return values to verify the call happened
successfully. There are some memory mapping calls that I have left out
since they are working while the interrupt is not.

Things seem to work for the most part because I can read/write data
through a memory map and verify the IndustryPack modules on the carrier
through their header. The memory map is still working sufficiently well
that I can program up one of the IndustryPack modules to generate an
interrupt every 2 seconds or so. Prior to my changes for 2.6.22 this
worked quite well. Since it is the interrupt portion of this game that
is giving me grief, lets stick with just that. apc8620_handler is:

static irqreturn_t apc8620_handler (int irq,
                                                               void
*did)
{
  printk (KERN_NOTICE "apc8620: did (0x%lx)\n", (unsigned long)did);
  <... other irrelevant steps ...>
  return IRQ_HANDLED;
}

I would then expect that every two seconds or so I would see a message
from apc8620_handler pop up. Instead I see nothing. Poking around I see
that the kernel module is loaded and attached to my devices and set for
IRQ 10:

lsmod:                          -> acromag8620          4207556  0 
cat /proc/devices       -> 46 apc8620
cat /proc/interrupts -> 10:          0   IO-APIC-edge      apc8620

With /proc/interrupts, LOC keeps growing at a rate faster than what my
hardware is generating and I have no idea what LOC means, but ERR and
MIS (I take it to mean error and missed respectively) are both 0 and
remain 0 indefinitely.

In /var/log/messages, I do not see any missing interrupt messages or any
other report indicating that there is some trouble.

Assuming no one sees the error I am making right off the bat and would
like me to probe the interrupt system a little bit more, please give me
a suggestion as to where to poke. There is lots of code there and I
would prefer to have guided poke over a random one.

Anyway, I read through linux/interrupts.h looking for some bit, flag, or
call that I have omitted but found nothing. I understand why the
interrupt handlers have changed, but the changes made should not be
causing this problem.

Again, any and all help in finding my lost interrupt is much
appreciated.

Lastly, I would be happy to give out the entire module to anyone who
requests it, but it is about 550 lines so I did not want to attach it to
this already long post.

-- 
Al Niessner
818.354.0859

All opinions stated above are mine and do not necessarily reflect those
of JPL or NASA.

--------
|  dS  | >= 0
--------

^ permalink raw reply	[flat|nested] 17+ messages in thread