1. 23 10月, 2010 1 次提交
  2. 19 10月, 2010 1 次提交
    • Y
      x86: ioapic: Call free_irte only if interrupt remapping enabled · 9717967c
      Yinghai Lu 提交于
      On a system that support intr-rempping when booting with "intremap=off"
      
      [  177.895501] BUG: unable to handle kernel NULL pointer dereference at 00000000000000f8
      [  177.913316] IP: [<ffffffff8145fc18>] free_irte+0x47/0xc0
      ...
      [  178.173326] Call Trace:
      [  178.173574]  [<ffffffff810515b4>] destroy_irq+0x3a/0x75
      [  178.192934]  [<ffffffff81051834>] arch_teardown_msi_irq+0xe/0x10
      [  178.193418]  [<ffffffff81458dc3>] arch_teardown_msi_irqs+0x56/0x7f
      [  178.213021]  [<ffffffff81458e79>] free_msi_irqs+0x8d/0xeb
      
      Call free_irte only when interrupt remapping is enabled.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4CBCB274.7010108@kernel.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9717967c
  3. 12 10月, 2010 31 次提交
  4. 01 10月, 2010 1 次提交
  5. 16 9月, 2010 2 次提交
    • S
      x86, intr-remap: Remove IRTE setup duplicate code · 62a92f4c
      Suresh Siddha 提交于
      Remove IRTE setup duplicate code with prepare_irte().
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <20100827181049.095067319@sbsiddha-MOBL3.sc.intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      62a92f4c
    • S
      x86, intr-remap: Set redirection hint in the IRTE · 75e3cfbe
      Suresh Siddha 提交于
      Currently the redirection hint in the interrupt-remapping table entry
      is set to 0, which means the remapped interrupt is directed to the
      processors listed in the destination. So in logical flat mode
      in the presence of intr-remapping, this results in a single
      interrupt multi-casted to multiple cpu's as specified by the destination
      bit mask. But what we really want is to send that interrupt to one of the cpus
      based on the lowest priority delivery mode.
      
      Set the redirection hint in the IRTE to '1' to indicate that we want
      the remapped interrupt to be directed to only one of the processors
      listed in the destination.
      
      This fixes the issue of same interrupt getting delivered to multiple cpu's
      in the logical flat mode in the presence of interrupt-remapping. While
      there is no functional issue observed with this behavior, this will
      impact performance of such configurations (<=8 cpu's using logical flat
      mode in the presence of interrupt-remapping)
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <20100827181049.013051492@sbsiddha-MOBL3.sc.intel.com>
      Cc: Weidong Han <weidong.han@intel.com>
      Cc: <stable@kernel.org> # [v2.6.32+]
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      75e3cfbe
  6. 20 8月, 2010 1 次提交
    • D
      x86, apic: Fix apic=debug boot crash · 05e40760
      Daniel Kiper 提交于
      Fix a boot crash when apic=debug is used and the APIC is
      not properly initialized.
      
      This issue appears during Xen Dom0 kernel boot but the
      fix is generic and the crash could occur on real hardware
      as well.
      Signed-off-by: NDaniel Kiper <dkiper@net-space.pl>
      Cc: xen-devel@lists.xensource.com
      Cc: konrad.wilk@oracle.com
      Cc: jeremy@goop.org
      Cc: <stable@kernel.org> # .35.x, .34.x, .33.x, .32.x
      LKML-Reference: <20100819224616.GB9967@router-fw-old.local.net-space.pl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      05e40760
  7. 13 8月, 2010 1 次提交
  8. 31 7月, 2010 1 次提交
  9. 10 6月, 2010 1 次提交
    • E
      x86, irq: Rename gsi_end gsi_top, and fix off by one errors · a4384df3
      Eric W. Biederman 提交于
      When I introduced the global variable gsi_end I thought gsi_end on
      io_apics was one past the end of the gsi range for the io_apic.  After
      it was pointed out the the range on io_apics was inclusive I changed
      my global variable to match.  That was a big mistake.  Inclusive
      semantics without a range start cannot describe the case when no gsi's
      are allocated.  Describing the case where no gsi's are allocated is
      important in sfi.c and mpparse.c so that we can assign gsi numbers
      instead of blindly copying the gsi assignments the BIOS has done as we
      do in the acpi case.
      
      To keep from getting the global variable confused with the gsi range
      end rename it gsi_top.
      
      To allow describing the case where no gsi's are allocated have gsi_top
      be one place the highest gsi number seen in the system.
      
      This fixes an off by one bug in sfi.c:
      Reported-by: Njacob pan <jacob.jun.pan@linux.intel.com>
      
      This fixes the same off by one bug in mpparse.c:
      
      This fixes an off unreachable by one bug in acpi/boot.c:irq_to_gsi
      Reported-by: NYinghai <yinghai.lu@oracle.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <m17hm9jre7.fsf_-_@fess.ebiederm.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      a4384df3