Registering interrupt with irq from pci_irq_vector(9) function results in "No irq handler for this function"?

1
votes

I am writing a device driver that services the interrupts from the device. The device has only one MSI interrupt vector, so I poll the irq with pci_irq_vector(dev, 0), receive the irq, and register the interrupt. This is shown in the following code snippet (equivalent to what I have minus error handling):

retval = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_MSI);
irq = pci_irq_vector(dev, 0);
retval = request_irq(irq, irq_fnc, 0, "name", dev);

This all completes successfully and without warning (at least with dmesg). Yet when the interrupt comes in, I get the error.

kernel:do_IRQ: 0.xxx No irq handler for this vector (irq -1)

The xxx appears to be an arbitrary number that changes every time the driver is loaded, but does not match the irq number. Instead, it matches the last two hex digits of the message data sent with the MSI interrupt as read from the MSI capability structure. Trying to request an irq of this number returns EINVAL which I think means that it's not associated with any PCI device. What does this number mean anyway?

Something that may be important to note, I am actually manually triggering this interrupt from the host side due to limitations with the device. I am reading the interrupt address and data from the capability structure then instructing the device to write the data to that address.

How would I go about further debugging this? Does anything from my description stand out as suspicious? Any help would be appreciated.

2
linux-kernellinux-device-driverpci-e
Triggering the interrupt using a dword write behaves exactly the same as an MSI. – prl
The low 8 bits of the message data is the vector number, which is an index into the vector table (IDT). – prl

2 Answers

0
votes

Does this particular irq show when you type cat /proc/interrupts? Maybe you can get the correct irq number from there, as well as other info like where it is attached and what driver is associated with this interrupt line!

0
votes

So the problem ended up being in the order of things. To manually create the interrupt, I had read the config space for the interrupt address and data before allocating interrupts. While obvious in retrospect, allocating the irq vectors for the device writes the appropriate data to the config space. Hence, using the preexisting value in the message data field would point to an irq vector that does not exist.