Comment 50 for bug 1598312

The IO_APIC_route_entry initialized in the mp_setup_entry() has mask=0 even though IRQs have not been enabled at that point in the kernel initialization. And since there is no other field where the kernel would remember whether IRQs have been enabled, the early "chip->irq_set_affinity(...)" from setup_ioapic_dest() actually enables IRQs way before the necessary structures have been initialized.

I've also tried to move the setup_ioapic_dest() call to a different place during the initialization. When it's before acpi_bus_init() in acpi_init(), it's broken. If it's after that, everything is OK.

This bug can be fixed in several ways. In my order of preference:

1. Revert 1f934641294ca2e09016c689862378fbb15da4d4,
      and 0be275e3a5607b23f5132121bca22a10ee23aa99.
   The commit message of the latter does not match reality,
   the so-called "cached" entry is not what's been written,
   so returning to RMW operation is preferable.

2. Initialize the IO_APIC_route_entry with mask=1 and update
   this flag when interrupts are enabled/disabled.

3. Move setup_ioapic_dest() after acpi_bus_init() in acpi_init(),
   or to another appropriate place inside acpi_bus_init().

4. Revert 4857c91f0d195f05908fff296ba1ec5fca87066c.
   (This has already been refused by Thomas Gleixner.)

I can try and prepare a patch but the maintainer (Thomas Gleixner) needs to decide which approach to take. I'm not going to unnecessarily write multiple patches.