Opened 17 months ago

Last modified 10 months ago

#9180 in-progress bug

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

Reported by: Joshua Owned by: mmlr
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: pci irq routing Cc:
Blocked By: Blocking: #7665
Has a Patch: no Platform: x86

Description

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.

Attachments (2)

syslog (410.0 KB) - added by Joshua 17 months ago.
acpi_namespace (17.7 KB) - added by Joshua 17 months ago.

Download all attachments as: .zip

Change History (10)

Changed 17 months ago by Joshua

comment:1 Changed 17 months ago by luroh

  • Blocking 7665 added

comment:2 Changed 17 months ago by 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.

Last edited 17 months ago by mmlr (previous) (diff)

comment:3 Changed 17 months ago by Joshua

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

comment:4 Changed 17 months ago by mmlr

  • Owner changed from axeld to mmlr
  • Status changed from new to in-progress

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.

Changed 17 months ago by Joshua

comment:5 Changed 17 months ago by Joshua

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

comment:6 Changed 10 months ago by 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.

comment:7 follow-up: Changed 10 months ago by 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.

comment:8 in reply to: ↑ 7 Changed 10 months ago by 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.

Note: See TracTickets for help on using tickets.