PANIC: unable to find irq routing for PCI 1:0:1

[Joshua]

When trying to boot on an IBM ThinkCentre M51, hrev44678 panics with the following error:

PANIC: unable to find irq routing for PCI 1:0:1 (​KDL photograph)

When I proceed with “continue”, it boots and everything seems to work. The only extension card inside is a PCI Express video card. The Syslog is attached.

[mmlr]

I've looked over the code with the given PCI information from the syslog but couldn't find anything sticking out. The only thing that came to mind, also possibly connected to #9165, is that we still don't scan a possible PCI Express root bridge for routing tables. Can you please attach the output of "cat /dev/acpi/namespace" here so that we can check for that case, i.e. if there is a PCI Express root bridge with a _PRT method that we're not taking into account.

[Joshua]

I can't access the computer until the weekend, I'll post the output then.

[mmlr]

One thing is for certain: The error should actually propagate upwards and cause the IO-APIC not to be used. I'm going to fix this later on, though it will probably cause a regression for you until the root cause is fixed.

I've noticed that both of the machines, the one here and the one in #9165 are of the Pentium 4 era. These are still relatively "early" in ACPI terms and may not really do things like it is done for current hardware. At least having the PCI Express bus separately is not so common on current implementations AFAICT.

It is theoretically possible to map the separate PCIe roots to PCI busses, but it requires the use of the _BBN field and comparing it to the BIOS set bus number on the PCI host bridge. This is at least inconvenient for Haiku, as the PCI module already sets up the busses and by that overwrites the BIOS configured bus numbers before the interrupt routing is determined. So to implement this mapping one would have to store these original values somehow in the PCI module and expose a way to get at them.

In current hardware implementations the PCIe host bridges are usually enumerated as PCI devices under the normal PCI root (this is the case here as well from a PCI point of view) and then the ACPI tables simply follow that and put the PCIe root as a device node on the PCI parent. This way a simple 1:1 mapping while enumerating both busses can be done. This is what is currently implemented in Haiku.

A possibly better approach to this whole mess and back and forth with PCI would be to make the PCI module responsible for the whole interrupt routing mechanism. This would make sense as what is currently done is really just PCI interrupt routing, not any kind of other interrupt routing (as there aren't any other interrupt sources that use this kind of routing on x86). So putting it in the PCI module would make sense. It would reduce the knowledge and redundancy the kernel has about PCI for this task at least, which would be much cleaner.

[Joshua]

You can find the output of “cat /dev/acpi/namespace” in the file “acpi_namespace” that I have attached.

[korli]

Hello Joshua, it seems the acpi_namespace output you attached is incomplete. That could be a bug, but could you please try again the command and see if the result is the same? Thanks.

[tqh]

No, it's complete, it's just that the shutting down in the namespace driver causes the 'bad semaphore' message and the tree ends that way as it is printed line by line it would need processing the whole tree to have a better visual.

[korli]

Replying to tqh:

No, it's complete, it's just that the shutting down in the namespace driver causes the 'bad semaphore' message and the tree ends that way as it is printed line by line it would need processing the whole tree to have a better visual.

I fixed the incomplete read in hrev45789. Here at least I get more lines now than before :) That said, I agree it could be a bit improved.

[kallisti5]

Please give hrev51032 or later a try. While the core issue for this one wasn't fixed.. it should help the system power through the problem and boot anyway with the devices missing IRQ mapping simply not working with a warning in syslog.

[kallisti5]

Since there has been no activity in > 1 month, i'm going to assume this one is resolved. Feel free to re-open if seen again.