Re: dmesg: PCI interrupts are no longer routed automatically.........

[linux-os]

On Tue, 4 Jan 2005, Bjorn Helgaas wrote:

> On Tue, 2005-01-04 at 13:53 -0500, linux-os wrote:
>
> > I note that pci_enable_device() needs to be executed __before__
> > the IRQ is obtained on 2.6.10, otherwise you get the wrong IRQ
> > (IRQ10 on this system)B.
>
> Right.
>
> > This doesn't seem to be correct since the IRQ connection was set
> > by the BIOS and certainly shouldn't be changed. On this system,
> > interrupts that were not shared on 2.4.n and early 2.6.n end
> > up being shared... See IRQ18 below.
>
> It's not that we are changing the IRQ, it's just that we now
> do the ACPI routing at the time the driver claims the device,
> rather than doing all the ACPI routing at boot-time.  The
> old strategy messed with IRQs that might never be used (which
> broke some things), and also didn't work for hot-plug PCI
> root bridges.
>
> Back to my original question, do you have a device that
> only works when you use "pci=routeirq"?  If so, what is
> it and what driver does it use?
No.
I modified our drivers to accommodate the new scheme. The problem
is that I don't feel warm and fuzzy about enabling a device
__before__ an IRQ handler is in place to handle the IRQ.
For instance,  Level interrupts from PLX chips on the PCI bus
can (read do) generate interrupts when some of the BARS are
being configured. Once you get an unhandled interrupt, you
are dead because there's nothing to reset the line.

The new scheme requires that the device be enabled to get
the correct IRQ. If you did this work, maybe it would
be much better if you added a pci_set_irq() call instead
of combining your routing with enabling the device?

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
                 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/