Hi Nikolai, > > Changes from v1: > > > > - preinitialise `dev' in `pirq_find_router' for `for_each_pci_dev', > > > > - avoid calling `pirq_try_router' with null `dev'. > > --- > > arch/x86/pci/irq.c | 64 > > ++++++++++++++++++++++++++++++++++++----------------- > > 1 file changed, 44 insertions(+), 20 deletions(-) > > > > linux-x86-pirq-router-nodev.diff > > Success! > Here is new log: > > https://pastebin.com/QXaUsCV4 This is great news, thank you for doing this verification! I have since discovered and posted a fix for an issue with our PIRQ routing code that turned out incapable of routing interrupts behind PCI-to-PCI bridges, which were sometimes used even on classic PCI option cards (I think I have at least two such devices) either to bundle multiple devices or to meet PCI bus load limits. Such devices may work regardless if the BIOS has been developed enough to handle them and assign an IRQ number, but surely they make the likelihood of interrupt sharing rise considerably, so I think the more of them we can handle ourselves the better. Plus these days now that PCIe has come into picture you can get quite complex topologies with multiple logical PCI-to-PCI bridges via external expansion even with classic PCI systems. So I have also posted a PIRQ router implementation for the Intel SIO southbridge and I have also identified further two Intel devices, the IB ISA bridge and the PCEB/ESC EISA bridge combo, that have their PIRQ routers documented in my resources but not handled in Linux. I'll see if I can find some time the following days to get them implemented too just for the sake of people experimenting with odd hardware. Have you tried contacting Nvidia about your ALI chipset? Back in the day I tried to avoid undocumented stuff and Intel was reasonably open about most of their chipsets. Maciej
