>>> We should never have had a problem with un-connected interrupt lines
>>> consuming vectors, as the vectors are handed out at run-time
>>> only when interrupts are requested by drivers.
>>
>>Incorrect. By being requested by drivers I assume you mean by
>>request_irq. assign_irq_vector is called long before request_irq
>>and in fact there is currently not a call from request_irq to
>>assign_irq_vector. Look where assign_irq_vector is called in
>io_apic.c
Hmmm, on Natalie's ping, I looked at this again.
setup_IO_APIC_irqs() actually consumes only 16 vectors.
This is because it only sets up the IRQs for pins
found with find_irq_entry(), which searches mp_irqs[]
which at this point contains only the legacy identify mappings.
The PNP code then takes a swing at things, and it registers
a handful of gsi's, but they are all duplicates of the legacy
mappings already set-up, so no additional vectors are consumed.
So on a big system, the large quantity of vectors will not be consumed
at
IOAPIC initialization time, but later at device probe time.
Not via request_irq(), but via pci_enable_device():
pci_enable_device()
pci_enable_device_bars()
pcibios_enable_device()
pcibios_enable_irq() -> acpi_pci_irq_enable()
acpi_register_gsi()
mp_register_gsi()
io_apic_set_pci_routing()
entry.vector = assign_irq_vector(irq)
So except for the legacy IRQs, we are already allocating the vectors
on-demand, and that doesn't need to be fixed.
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
