PCI bus_manager does not assign IRQs

[marcusoverhagen]

The PCI bus_manager does no IRQ line assignment

[mmlr]

(In #2401) In fact this is a duplicate of bug #5. From the syslog it tells that a UHCI and an EHCI controller were found, but that both could not be used because they have an invalid IRQ assignment (or none at all probably). As this should automatically resolve as soon as bug/enhancement #5 is done, it shouldn't really be necessary to keep this bug open.

[mmlr]

(In #2620) The cause can be seen in the first screenshot at the top. Both the UHCI and EHCI controllers present have invalid IRQ assignments, which means that the BIOS didn't initialize interrupt routing for them. That means, this is in fact a duplicate of bug #5. If it works when you have a IDE disk connected this probably causes the BIOS to do some additional setup that it doesn't do when that's not the case. Maybe there are some USB legacy settings in the BIOS that you can try changing, otherwise there's not much you can currently do.

[tqh]

Apparently trac decided to change version when I added myself to CC. I don't know what it is supposed to be so leaving as is.

[axeld]

(In #4568) No update, assuming diagnosis is correct.

[mmadia]

(In #5571) From my understanding, the FreeBSD wlan drivers are expecting IRQ Routing.

[mmadia]

(In #5511) Replying to colin:

... the right way to do it, would be to implement irq routing by using ACPI in Haiku. As far as I know someone is working on that already.

Setting #5 as a blocker.

[mmadia]

(In #5372) Replying to kallisti5:

<@mmlr_mc> in freebsd they take care to not share interrupts, so their drivers usually don't behave well when we doing it anyway

I'm guessing this can be blocked by #5 as well?

[jackburton]

(In #5511) Fixed for me as well.

[tangobravo]

To me this seems one of the biggest blockers holding up further Haiku releases. Is anyone working on it, or planning to? It's assigned to Marcus, but I'm not sure he has the time to really look into it. Tqh has done lots of the work on ACPI recently, but I think I read somewhere he thought he lacked the necessary knowledge to tackle this one (correct me if I'm wrong there). Given many people's hardware failures are eventually blamed on this, I'm sure a decent bounty could be raised if someone with the necessary skills could name their price! :)

[mmlr]

It's a question of whether it's still relevant to implement the legacy PCI configuration. On reasonably modern systems routing is done through the IO-APIC and configured through ACPI or MSIs are used which don't need the extra hardware at all anyway.

[gsf]

Landed here via #2620. I would certainly contribute toward a bounty to see this fixed.

[tqh]

Got some feedback on IRC with problem same as comment 4.

[admiral0]

I'm having issue as in comment 4 as said by tqh. How does Linux handle this situation?

[tqh]

If you want to hack on this I think ACPI does what it should do.
There is a faulty check in source:haiku/trunk/src/system/kernel/arch/x86/irq_routing_table.cpp#109 to 113 that can be removed. (If I'm not mistaken).
After that it did iterate through a lot of things.

[tqh]

I'm not sure what source:haiku/trunk/src/system/kernel/arch/x86/irq_routing_table.cpp#167 - 179 should do though. To me it looks like it returns the status of the last iteration of the while-loop, can that really be ok?

[tqh]

Added a patch that reads all irq_routing_entries from ACPI. This makes qemu use ioapic it seems, but on real hardware I think things are missing, it seems int14 is missed and a root partition isn't found.

The problems which always caused it to fail before was several:

• The check if buffer.pointer is a ACPI_PACKAGE always failed. It is not. We now trust the B_OK status completly.
• We failed as soon as a ACPI device didn't have irq routing information. Not all of them have, now we read the routing entries from all devices and only fail if we find none.

Also since the pci_bus and pci_device was unused I removed that complexity. Might be needed, if not we can also remove the passing of pci_module I guess.

This is as far as I can go, when it comes to ioapic it's way over my head.

[tqh]

Formatting edit:

The problems which always caused it to fail before was several:

• The check if buffer.pointer is a ACPI_PACKAGE always failed. It is not. We now trust the B_OK status completly.
• We failed as soon as a ACPI device didn't have irq routing information. Not all of them have, now we read the routing entries from all devices and only fail if we find none.

[tqh]

Current WIP, arch_int 682 for-loop always sets irq -1...

[anevilyak]

(In #6955) Those are IO-APIC IRQs. Adding ticket #5 as a blocker.

[anevilyak]

(In #4510) Your problem is most likely related to interrupt sharing. You have two ethernet controllers and a USB controller sharing IRQs, which is something most of the FreeBSD-based network drivers aren't really geared towards dealing with since they assume the OS has configured everything such that that situation doesn't happen. Another victim of #5.

[korli]

(In #6955) Thanks for the feedback!

[anevilyak]

(In #7127) Another victim of #5.

[umccullough]

I pledge $25 via paypal to the individual that gets this task completed so that it may finally resolve my interrupt sharing issues on my Acer Aspire One netbook.

[tqh]

I'm sorry that real life is so busy for me right now, so can't really promise anything.

[anevilyak]

(In #7452) Cool, that makes this a dupe of #5. Enjoy!

[mmlr]

I've completed the work on implementing IO-APIC support (adding PCI interrupt routing, configuration and PCI config updates) between hrev41328 and hrev41402. With that, configurations that previously didn't assign legacy IRQs should now do so via ACPI. Please retest the affected configurations with an installation that includes those changes and enable the IO-APIC by checking the "Enable IO-APIC" entry in the bootloader safemode options. Note that using the IO-APIC currently defaults to off, so you really need to enter the bootloader menu and explicitly enable it.

What issues to look for when using the IO-APIC:

• If routing isn't possible do to some unexpected event, the routing code will panic throwing you into KDL.
• If just some interrupts aren't routed (because matching the interrupt routing table to PCI devices failed for example) you would notice that by the affected devices failing. For example USB not being able to address plugged in devices, audio cards not working or not being detected at all, network cards failing to receive data and so on.
• If you happen to have a non-legacy disk controller where you boot from (AHCI mostly) it's also possible that the boot process would hang, possibly progressing very slowly with messages of "recovering lost interrupts" printed to debug output.
• If some interrupts are routed to the wrong vectors, it is possible that the affected devices fail to work and that the syslog is filled with "more than 99% of interrupts on vector X are unhandled" messages. It is also possible that such systems appear to hang completely.
• It is possible that, due to using ACPI for interrupt configuration but not setting the corresponding ACPI support bits, MSI (Message Signaled Interrupts) stop working. You would experience this as network cards failing that use a driver based on the FreeBSD compatibility layer that use the MSI capability.

Please report any of those issues (or ones I forgot about but are linked to enabling the IO-APIC) in new tickets. I will close duplicate tickets as duplicates if needed, so please open new tickets if you're not sure an already reported ticket matches your problem.

In most cases syslogs or serial debug output from a boot would be helpful to identify the problem. You can verify that you are running on IO-APIC by checking the syslog for the line "using ioapic for interrupt routing". Immediately before that line the used IRQ routing table is printed. Please include that, and ideally the whole part where the PCI configuration is printed, in reports.

You can check the resulting interrupt configuration by entering KDL and running the "ints" debugger command. It will print the list of installed interrupt handlers and the vectors they are assigned to. Interrupts 0-15 are generally called ISA interrupts, although PCI interrupts are mixed into those in legacy PIC mode, because there simply are only 16 interrupts available. Depending on the configuration of your system and the firmware it uses, the resulting interrupt vectors will change with enabling the IO-APIC. Usually vectors 16-19 are now used for the PCI interrupt lines, depending on system configuration this might as well be 20-23 or both. So if you see handlers installed on those numbers they are definitely using the IO-APIC. Vector starting from 24 and up are Message Signaled Interrupts (MSIs) that are used only by FreeBSD network drivers using the FreeBSD compatibility layer right now. The vectors above 200 are used for processor to processor communication, the APIC timer, spurious interrupts, SMP error interrupts and such and are triggered inside the Local APIC of the processors (so not using the IO-APIC).

Note that it is possible that even after enabling the IO-APIC parts or even all of the vectors in use by PCI devices still reside in the legacy ISA range of 0-15. This is firmware and configuration dependent and, as long as the devices actually work, not a bug.

Relevance to this ticket: Setting up the IO-APIC involves switching the interrupt model. This for one makes hardwired "PCI interrupt pin -> IO-APIC input" connections available. Additionally the setup includes the configuration of so called PCI interrupt link devices (where available), making also the "PCI interrupt pin -> interrupt link device -> IO-APIC input" connections available. This means that all devices that are physically routed in the system are assigned a proper IRQ and, since this information is made available via the PCI configuration space, drivers will be able to attach to these. Long story short: IO-APIC interrupt routing replaces the legacy configuration that this ticket is about. So unless additional configuration is missing (memory resources, ticket #3; IO port resources, ticket #4), your devices should now work.

[umccullough]

Replying to umccullough:

I pledge $25 via paypal to the individual that gets this task completed so that it may finally resolve my interrupt sharing issues on my Acer Aspire One netbook.

My AA1 works pretty good now - audio plays without issues during the use of USB and ethernet. Wifi seems to be working pretty good now - when I disable the io-apic again, then it starts having problems.

Great work! Payment sent - I threw an extra $5 in for good measure ;)

[humdinger]

I just chipped in a few euros myself. This was an important ticket to solve.

[luroh]

(In #5866) Sounds good, thanks for reporting back. Closing this one as fixed.

[scottmc]

Is this one finished now?

[mmlr]

Replying to scottmc:

Is this one finished now?

Well. This ticket isn't really done (and probably won't ever get done) in the sense that the PCI bus_manager still doesn't assign interrupt lines (i.e. no PNPBIOS). However with ACPI PCI Interrupt Routing Table support and IO-APIC support being available now, the need for this feature isn't really there anymore and the symptoms it caused are gone as well for most moderately modern machines. As explained earlier, machines that don't provide support for ACPI PRTs and IO-APICs usually don't have this problem at all because either the BIOS initializes all devices in the first place or at least they provide the "PnP OS installed" BIOS option by which this can be enforced.

So I'm really a bit undecided. Leave this open but close all the blocked bugs (already done for the most part)? Close this one as "wontfix"? Close it as fixed as the symptoms it causes should be gone?

[tqh]

I'd vote for 'Close this one as "wontfix"' with the comments you already given and so nobody assumes problems are because of this bug.

[scottmc]

All but one of the blocking tickets have been closed out, and that one just needs confirmation as to whether it's been fixed or not. So I say let's close this one out as being fixed, seeing as the reported symptoms have gone away.