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 run. 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!