summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorStefan Bader <stefan.bader@canonical.com>2008-09-27 11:07:30 -0400
committerGreg Kroah-Hartman <gregkh@suse.de>2008-10-22 14:13:11 -0700
commit4c1f10b9281efa585cb616ce25b6e7b408e47229 (patch)
tree1abb44ba2ca42913d0dc2a10998ec8c00a1bbbb9
parentafc84dacd12c94d2ade2fbc45fa2e4b57da37b65 (diff)
x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap.
Not in upstream above 2.6.27 due to change in the way this code works (has been fixed differently there.) Someone from the community found out, that after repeatedly unloading and loading a device driver that uses MSI IRQs, the system eventually assigned the vector initially reserved for IRQ0 to the device driver. The reason for this is, that although IRQ0 is tied to the FIRST_DEVICE_VECTOR when declaring the irq_vector table, the corresponding bit in the used_vectors map is not set. So, if vectors are released and assigned often enough, the vector will get assigned to another interrupt. This happens more often with MSI interrupts as those are exclusively using a vector. Fix this by setting the bit for the FIRST_DEVICE_VECTOR in the bitmap. Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-rw-r--r--arch/x86/kernel/io_apic_32.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/arch/x86/kernel/io_apic_32.c b/arch/x86/kernel/io_apic_32.c
index 4dc8600d9d20..ad745cd88cd8 100644
--- a/arch/x86/kernel/io_apic_32.c
+++ b/arch/x86/kernel/io_apic_32.c
@@ -2264,6 +2264,9 @@ void __init setup_IO_APIC(void)
for (i = FIRST_SYSTEM_VECTOR; i < NR_VECTORS; i++)
set_bit(i, used_vectors);
+ /* Mark FIRST_DEVICE_VECTOR which is assigned to IRQ0 as used. */
+ set_bit(FIRST_DEVICE_VECTOR, used_vectors);
+
enable_IO_APIC();
if (acpi_ioapic)