1. 17 12月, 2008 1 次提交
    • M
      x86: fix build error with post-merge of tip/cpus4096 and rr-for-ingo/master. · c8cae544
      Mike Travis 提交于
      Ingo Molnar wrote:
      
      > allyes64 build failure:
      >
      > arch/x86/kernel/io_apic.c: In function ‘set_ir_ioapic_affinity_irq_desc’:
      > arch/x86/kernel/io_apic.c:2295: error: incompatible type for argument 2 of
      > ‘migrate_ioapic_irq_desc’
      > arch/x86/kernel/io_apic.c: In function ‘ir_set_msi_irq_affinity’:
      > arch/x86/kernel/io_apic.c:3205: error: incompatible type for argument 2 of
      > ‘set_extra_move_desc’
      > make[1]: *** wait: No child processes.  Stop.
      
      Here's a small patch to correct the build error with the post-merge tree.
      Built and boot-tested.  I'll will reset the follow on patches in my brand
      new git tree to accommodate this change.
      
      Fix two references in io_apic.c that were incorrect.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c8cae544
  2. 13 12月, 2008 1 次提交
  3. 08 12月, 2008 4 次提交
  4. 23 11月, 2008 1 次提交
  5. 21 11月, 2008 1 次提交
    • M
      x86: Fix interrupt leak due to migration · 0ca4b6b0
      Matthew Wilcox 提交于
      When we migrate an interrupt from one CPU to another, we set the
      move_in_progress flag and clean up the vectors later once they're not
      being used.  If you're unlucky and call destroy_irq() before the vectors
      become un-used, the move_in_progress flag is never cleared, which causes
      the interrupt to become unusable.
      
      This was discovered by Jesse Brandeburg for whom it manifested as an
      MSI-X device refusing to use MSI-X mode when the driver was unloaded
      and reloaded repeatedly.
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0ca4b6b0
  6. 10 11月, 2008 1 次提交
  7. 06 11月, 2008 1 次提交
    • B
      x86: don't allow nr_irqs > NR_IRQS · c78d0cf2
      Ben Hutchings 提交于
      Impact: fix boot hang on 32-bit systems with more than 224 IO-APIC pins
      
      On some 32-bit systems with a lot of IO-APICs probe_nr_irqs() can
      return a value larger than NR_IRQS. This will lead to probe_irq_on()
      overrunning the irq_desc array.
      
      I hit this when running net-next-2.6 (close to 2.6.28-rc3) on a
      Supermicro dual Xeon system.  NR_IRQS is 224 but probe_nr_irqs() detects
      5 IOAPICs and returns 240.  Here are the log messages:
      
      Tue Nov  4 16:53:47 2008 ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
      Tue Nov  4 16:53:47 2008 IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
      Tue Nov  4 16:53:47 2008 ACPI: IOAPIC (id[0x02] address[0xfec81000] gsi_base[24])
      Tue Nov  4 16:53:47 2008 IOAPIC[1]: apic_id 2, version 32, address 0xfec81000, GSI 24-47
      Tue Nov  4 16:53:47 2008 ACPI: IOAPIC (id[0x03] address[0xfec81400] gsi_base[48])
      Tue Nov  4 16:53:47 2008 IOAPIC[2]: apic_id 3, version 32, address 0xfec81400, GSI 48-71
      Tue Nov  4 16:53:47 2008 ACPI: IOAPIC (id[0x04] address[0xfec82000] gsi_base[72])
      Tue Nov  4 16:53:47 2008 IOAPIC[3]: apic_id 4, version 32, address 0xfec82000, GSI 72-95
      Tue Nov  4 16:53:47 2008 ACPI: IOAPIC (id[0x05] address[0xfec82400] gsi_base[96])
      Tue Nov  4 16:53:47 2008 IOAPIC[4]: apic_id 5, version 32, address 0xfec82400, GSI 96-119
      Tue Nov  4 16:53:47 2008 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
      Tue Nov  4 16:53:47 2008 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
      Tue Nov  4 16:53:47 2008 Enabling APIC mode:  Flat.  Using 5 I/O APICs
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Acked-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c78d0cf2
  8. 16 10月, 2008 30 次提交