Intel 82599 NIC legacy (INTx) interrupts not being received

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
ri
Posts: 9
Joined: Mon Feb 05, 2018 11:18 am

Intel 82599 NIC legacy (INTx) interrupts not being received

Post by ri »

I've written a driver for the 82599. I'm now trying to enable interrupts rather than using a polling method.
My system has a PCIe bus, but I've enabled legacy (INTx) interrupts using the Command register in the PCI config space and disabled MSI and MSI-X in the capabilities list.
I've written a test code that enables an interrupt and then causes an interrupt though software. In the PCI Status register the Interrupt Status bit is set, so I'm assuming the interrupt has been sent by the device but I'm not receiving any interrupt and I've written dummy handlers for every interrupt. None of them are called.

I know the PCIe bus sends Assert_INTx and Deassert_INTx messages to emulate legacy interrupts in place of actual out-of-band connections with the APIC. I want to know if I'm missing something here. Is there something I need to do in the APIC to be able to receive and process these Assert_INTx and Deassert_INTx messages? Or for the PCIe bus to be able to send them?
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: Intel 82599 NIC legacy (INTx) interrupts not being recei

Post by Brendan »

Hi,
ri wrote:I know the PCIe bus sends Assert_INTx and Deassert_INTx messages to emulate legacy interrupts in place of actual out-of-band connections with the APIC. I want to know if I'm missing something here. Is there something I need to do in the APIC to be able to receive and process these Assert_INTx and Deassert_INTx messages? Or for the PCIe bus to be able to send them?
I'm guessing that you're not telling ACPI that you're planning to use the IO APIC (by using the "_PIC" method in its AML), so that (if necessary) it can do any chipset-specific things that might be needed to connect IRQs to the IO APIC instead of the PIC chips and so that ACPI's AML can and take this information into account in other AML methods; and possibly also not asking ACPI which IO APIC input device/s use and if those IO APIC inputs should be edge/level triggered or active high/low (so that it's possible for your code to configure each IO APIC input correctly and not end up with bizarre behaviour because the IO APIC is waiting for the wrong thing on one of its inputs - e.g. waiting for a falling edge but only seeing a transition from low to high).


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Post Reply