Opened 7 years ago

Closed 2 years ago

Last modified 13 months ago

#9180 closed bug (fixed)

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

Reported by: Joshua Owned by: kallisti5
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: pci irq routing Cc:
Blocked By: #13387 Blocking:
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 7 years ago.
acpi_namespace (17.7 KB) - added by Joshua 7 years ago.

Download all attachments as: .zip

Change History (15)

Changed 7 years ago by Joshua

Attachment: syslog added

comment:1 Changed 7 years ago by luroh

Blocking: 7665 added

comment:2 Changed 7 years 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 7 years ago by mmlr (previous) (diff)

comment:3 Changed 7 years ago by Joshua

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

comment:4 Changed 7 years ago by mmlr

Owner: changed from axeld to mmlr
Status: newin-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 7 years ago by Joshua

Attachment: acpi_namespace added

comment:5 Changed 7 years 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 6 years 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 Changed 6 years 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 6 years 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.

comment:9 Changed 2 years ago by kallisti5

Owner: changed from mmlr to kallisti5
Status: in-progressassigned

comment:10 Changed 2 years ago by kallisti5

Blocked By: 13387 added

comment:11 Changed 2 years ago by 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.

comment:12 Changed 2 years ago by kallisti5

Resolution: fixed
Status: assignedclosed

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.

comment:13 Changed 13 months ago by waddlesplash

Blocking: 7665 removed
Note: See TracTickets for help on using tickets.