The recent upgrade to the 2.6.24-based RT kernel seems to have broken the
ability on some systems to bind hardware interrupts to specific CPUs.
Empirically, this seems like it may only happen on nvidia/nforce-based motherboards.
On affected systems, echo'ing a processor mask into /proc/irq/#/smp_affinity is
successful (i.e. a subsequent cat of the file shows the desired value), but
/proc/interrupts continues to show all interrupts arriving on CPU0. This
capability worked correctly in the 2.6.21-based MRG kernel.
Created attachment 295360 [details]
patch to fix x86 64 irq smp affinity
It seems that x86_64 isn't honoring smp_affinity changes for level interrupts.
Looking into this, I found that the code to change the affinity is delayed
(CONFIG_GENERIC_PENDING_IRQ) to a better time to touch the apic. The changes
are made in the ack of the interrupt. But the code in the ack will not change
the apic if an irq is in progress.
On vanilla, this is fine, because the IRQ_INPROGRESS bit is cleared before
acking. But with threaded interrupts, we keep the IRQ_INPROGRESS bit set
through out the ack. This bit doesn't get cleared until after the thread is
The race that this is trying to prevent is not applicable when interrupts are
threaded. This patch will perform the update to the smp affinity of the irq in
the ack when interrupts are threaded, regardless of the IRQ_INPROGRESS bit.
I can confirm that Steven's patch fixed the issue on my machines. Thanks!