RE: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision

[Brown, Len]

>>> 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-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/