Interrupts asserted in PCI, but not fired

[Klakap]

I am rewriting my USB drivers to use interrupts, and on one computer two USB controllers are not firing interrupts. Problem is with UHCI controller and EHCI controller that are according to PCI Interrupt Line connected to IRQ 11. Interrupt status is asserted in UHCI/EHCI status registers, PCI Status Interrupt bit indicates that these controllers asserts interrupt, PIC has IRQ 11 unmasked and handler in IDT is initalized correctly, however PIC do not have IRQ 11 asserted, so handler is not called. It seems like there is something between controllers and PIC, that blocks interrupt signal.

As additional info, I found out that there are 7 devices that are connected to IRQ 11. One of these is ethernet card, that can fire IRQ 11 successfully. And I also found that there is also IDE controller that has constantly set PCI Status Interrupt bit, but it also do not generate interrupt. I do not use interrupts for IDE, so I usually disable them for this device, but even if I don't, it also do not assert interrupt in PIC.

What can cause such issue?

[rdos]

I am rewriting my USB drivers to use interrupts, and on one computer two USB controllers are not firing interrupts. Problem is with UHCI controller and EHCI controller that are according to PCI Interrupt Line connected to IRQ 11. Interrupt status is asserted in UHCI/EHCI status registers, PCI Status Interrupt bit indicates that these controllers asserts interrupt, PIC has IRQ 11 unmasked and handler in IDT is initalized correctly, however PIC do not have IRQ 11 asserted, so handler is not called. It seems like there is something between controllers and PIC, that blocks interrupt signal.

As additional info, I found out that there are 7 devices that are connected to IRQ 11. One of these is ethernet card, that can fire IRQ 11 successfully. And I also found that there is also IDE controller that has constantly set PCI Status Interrupt bit, but it also do not generate interrupt. I do not use interrupts for IDE, so I usually disable them for this device, but even if I don't, it also do not assert interrupt in PIC.

What can cause such issue?

The issue is that on modern hardware, with an APIC controller, the PCI interrupt line is not correct and needs to be determined through ACPI (or through probing). Another way to solve this is to use a 1ms timer for polling the schedules (I do that since IRQs fail to work on some hardware).

Generally speaking, you should first check for MSI or MSI-X support, and use this instead of PCI IRQ. Second, you might decide device interrupts are not really needed (UHCI, and perhaps OHCI and EHCI too, since you know how often the schedule is updated). Third, you might decide that you can probe for the correct interrupt line. Fourth, you might use ACPI to find the mapping.

[Octocontrabass]

It seems like there is something between controllers and PIC, that blocks interrupt signal.

Do these controllers require BIOS handoff? Was the handoff successful?

And I also found that there is also IDE controller that has constantly set PCI Status Interrupt bit, but it also do not generate interrupt. I do not use interrupts for IDE, so I usually disable them for this device, but even if I don't, it also do not assert interrupt in PIC.

What does the PCI topology look like? Is there a bridge that could be blocking interrupts for some devices and not others?

Where is your handler for the System Control Interrupt you've enabled?

[Klakap]

Thank you for replies. This computer is so old that it do not support MSI, so I can not use this way.

Do these controllers require BIOS handoff? Was the handoff successful?

Yes. This computer also has UHCI controller connected to IRQ 10 and it is working perfectly, so it seem to be problem only with raising interrupt.

Where is your handler for the System Control Interrupt you've enabled?

Good point. I somehow completely skipped through fact, that I need to take care of SCI. However even if I do not enable SMI, problem still remains.

What does the PCI topology look like? Is there a bridge that could be blocking interrupts for some devices and not others?

Maybe. There are two PCI-to-PCI bridges and one ISA Bridge. But I can not find informations how to configure them in regard of interrupts. May be problem in them?

[Octocontrabass]

But I can not find informations how to configure them in regard of interrupts.

The BIOS is supposed to initialize everything so you don't need to configure interrupt routing when you're using the PICs. If you do need to configure them, you would use ACPI, the $PIR table, or INT 0x1A AH=0xB1.

Since the PCI IDE controller's interrupts also don't work, you might have a problem with your code to enumerate PCI.

[Klakap]

Well, but where could be problem with enumerating PCI? I am using brute force scan, so I should not be missing any device. And because interrupts of other devices work, I am pretty sure that code for getting IRQ number is correct. Am I missing something?

[Octocontrabass]

When you enumerate PCI, you write to the command register on several devices. What happens if you don't do that?

Your code for detecting the base addresses for PCI IDE controllers is incorrect. The class code tells you whether you should check the BARs or use the legacy addresses.

[Klakap]

If I do not write to command register to disable interrupts, nothing changes.

Also I found out, that even through IDE controller in PCI has that it is connected to IRQ11, it generates IRQ14, and even through PCI Status Interrupt bit says that it is generating interrupt forever, in fact it is calling IRQ14 correctly.

[rdos]

If I do not write to command register to disable interrupts, nothing changes.

Also I found out, that even through IDE controller in PCI has that it is connected to IRQ11, it generates IRQ14, and even through PCI Status Interrupt bit says that it is generating interrupt forever, in fact it is calling IRQ14 correctly.

PCI is not generating specific IRQs. It pulls one of four interrupt lines, which then are routed to the interrupt controller in some largely undefined manner. The int num in PCI is purely informational and put there by BIOS. I think BIOS puts the IRQ number of the ordinary PIC controller there, so if you use the APIC instead, then the IRQ number might be incorrect. Instead, you need to follow the interrupt lines in PCI to find out how they are routed. You must use ACPI to do this. Alternatively, you probe the interupts by listening to all IRQs and triggering the IRQ in the PCI device.

[Klakap]

I am using PIC, so I think this number should be correct. I tried to add handlers to all PIC IRQs, but nothing was called, even through USBSTS of UHCI says that it is raising interrupt.

I runned Windows XP on this computer, and it found out, that no USB controller is in fact connected to IRQ10 or IRQ11. From point of APIC, there are three UHCI controllers on IRQ17/18/19 and one UHCI and one EHCI controller are sharing IRQ23. Because in my OS I detect three UHCI controllers on IRQ10 that are correctly raising interrupt, and one UHCI and EHCI on IRQ11 that do not raise interrupt, I think it is probable, that these two are those who share IRQ23. Does this mean that BIOS did not reroute these correctly and I need to write my driver for APIC, or maybe there is something else?

[rdos]

I was mostly guessing about what BIOS writes to the int num in PCI. It might be incorrect for PIC too, or maybe it assumes you are using APIC. Anyway, this is not reliable information, and so you need to use ACPI or detection.

For UHCI, I first check for MSI (which is unlikely) and as a last resort I use a 1 ms timer for "fall-back" when IRQs are not working. For older PCs with only PIC, I don't support ACPI, and so I use int num as the primary source and a 1 ms timer for "fall-back".

I think that if you have an APIC, you should use it as the default interrupt controller, even if it is a single core CPU. The PIC on this hardware is only for legacy software (DOS), and not for new implementations.

Also, I'm not sure that MSI or MSI-X actually work if you use the PIC.

[Octocontrabass]

Also I found out, that even through IDE controller in PCI has that it is connected to IRQ11, it generates IRQ14, and even through PCI Status Interrupt bit says that it is generating interrupt forever, in fact it is calling IRQ14 correctly.

This is also determined by the class code. When the class code indicates the IDE controller is running in legacy mode, it uses legacy IRQ14/IRQ15.

Does this mean that BIOS did not reroute these correctly and I need to write my driver for APIC, or maybe there is something else?

It could still be a problem with BIOS handoff. Some BIOSes get confused if you don't do the handoff the same way Windows does.

It could be a problem with legacy PIC IRQ routing. Since Windows XP uses the APIC, IRQ routing through the legacy PICs might not be initialized correctly. It's a good idea to use APIC, but if you don't want to, you can still try ACPI, $PIR, or INT 0x1A AH=0xB1 to fix the legacy PIC IRQ routing.