1. 17 Feb, 2006 1 commit
  2. 04 Feb, 2006 1 commit
  3. 11 Jan, 2006 5 commits
    • Andi Kleen's avatar
      [PATCH] x86_64: Some housekeeping in local APIC code · 11a8e778
      Andi Kleen authored
      Remove support for obsolete hardware and cleanup.
      - Remove checks for non integrated APICs
      - Replace apic_write_around with apic_write.
      - Remove apic_read_around
      - Remove APIC version reads used by old workarounds
      - Remove old workaround for Simics
      - Fix indentation
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Vivek Goyal's avatar
      [PATCH] x86_64: ioapic virtual wire mode fix · af5b9804
      Vivek Goyal authored
      o Currently, during kexec reboot, IOAPIC is re-programmed back to virtual
        wire mode if there was an i8259 connected to it. This enables getting
        timer interrupts in second kernel in legacy mode.
      o After putting into virtual wire mode, IOAPIC delivers the i8259 interrupts
        to CPU0. This works well for kexec but not for kdump as we might crash
        on a different CPU and second kernel will not see timer interrupts.
      o This patch modifies the redirection table entry to deliver the timer
        interrupts to the cpu we are rebooting (instead of hardcoding to zero).
        This ensures that second kernel receives timer interrupts even on a
        non-boot cpu.
      Signed-off-by: default avatarVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Eric W. Biederman's avatar
      [PATCH] x86_64: Memorize location of i8259 for reboots. · 1008fddc
      Eric W. Biederman authored
      Currently we attempt to restore virtual wire mode on reboot, which only
      works if we can figure out where the i8259 is connected.  This is very
      useful when we are kexec another kernel and likely helpful to an peculiar
      BIOS that make assumptions about how the system is setup.
      Since the acpi MADT table does not provide the location where the i8259 is
      connected we have to look at the hardware to figure it out.
      Most systems have the i8259 connected the local apic of the cpu so won't be
      affected but people running Opteron and some serverworks chipsets should be
      able to use kexec now.
      In addition this patch removes the hard coded assumption that the io_apic
      that delivers isa interrups is always known to the kernel as io_apic 0.
      There does not appear to be anything to guarantee that assumption is true.
      And From: Vivek Goyal <vgoyal@in.ibm.com>
        A minor fix to the patch which remembers the location of where i8259 is
        connected.  Now counter i has been replaced by apic.  counter i is having
        some junk value which was leading to non-detection of i8259 connected to
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Andi Kleen's avatar
      [PATCH] x86_64: Fix off by one in IOMMU check · ca8642f6
      Andi Kleen authored
      Fix off by one when checking if the machine has enougn memory to need IOMMU
      This caused the IOMMUs to be needlessly enabled for mem=4G
      Based on a patch from Jon Mason
      Signed-off-by: jdmason@us.ibm.com
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Andi Kleen's avatar
      [PATCH] x86_64: Dont't disable early PCI scan with apic · 7c0ac555
      Andi Kleen authored
      It might be still needed for non APIC related issues.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  4. 09 Dec, 2005 1 commit
    • Bob Moore's avatar
      [ACPI] ACPICA 20050930 · 50eca3eb
      Bob Moore authored
      Completed a major overhaul of the Resource Manager code -
      specifically, optimizations in the area of the AML/internal
      resource conversion code. The code has been optimized to
      simplify and eliminate duplicated code, CPU stack use has
      been decreased by optimizing function parameters and local
      variables, and naming conventions across the manager have
      been standardized for clarity and ease of maintenance (this
      includes function, parameter, variable, and struct/typedef
      All Resource Manager dispatch and information tables have
      been moved to a single location for clarity and ease of
      maintenance. One new file was created, named "rsinfo.c".
      The ACPI return macros (return_ACPI_STATUS, etc.) have
      been modified to guarantee that the argument is
      not evaluated twice, making them less prone to macro
      side-effects. However, since there exists the possibility
      of additional stack use if a particular compiler cannot
      optimize them (such as in the debug generation case),
      the original macros are optionally available.  Note that
      some invocations of the return_VALUE macro may now cause
      size mismatch warnings; the return_UINT8 and return_UINT32
      macros are provided to eliminate these. (From Randy Dunlap)
      Implemented a new mechanism to enable debug tracing for
      individual control methods. A new external interface,
      acpi_debug_trace(), is provided to enable this mechanism. The
      intent is to allow the host OS to easily enable and disable
      tracing for problematic control methods. This interface
      can be easily exposed to a user or debugger interface if
      desired. See the file psxface.c for details.
      acpi_ut_callocate() will now return a valid pointer if a
      length of zero is specified - a length of one is used
      and a warning is issued. This matches the behavior of
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
  5. 14 Nov, 2005 1 commit
    • James Cleverdon's avatar
      [PATCH] i386/x86-64: Share interrupt vectors when there is a large number of interrupt sources · 6004e1b7
      James Cleverdon authored
      Here's a patch that builds on Natalie Protasevich's IRQ compression
      patch and tries to work for MPS boots as well as ACPI.  It is meant for
      a 4-node IBM x460 NUMA box, which was dying because it had interrupt
      pins with GSI numbers > NR_IRQS and thus overflowed irq_desc.
      The problem is that this system has 270 GSIs (which are 1:1 mapped with
      I/O APIC RTEs) and an 8-node box would have 540.  This is much bigger
      than NR_IRQS (224 for both i386 and x86_64).  Also, there aren't enough
      vectors to go around.  There are about 190 usable vectors, not counting
      the reserved ones and the unused vectors at 0x20 to 0x2F.  So, my patch
      attempts to compress the GSI range and share vectors by sharing IRQs.
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@unisys.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  6. 14 Sep, 2005 1 commit
  7. 12 Sep, 2005 3 commits
  8. 09 Sep, 2005 1 commit
  9. 07 Sep, 2005 2 commits
  10. 24 Aug, 2005 1 commit
  11. 30 Jun, 2005 1 commit
  12. 25 Jun, 2005 1 commit
  13. 31 May, 2005 1 commit
  14. 20 May, 2005 1 commit
  15. 17 May, 2005 1 commit
  16. 01 May, 2005 1 commit
    • Jack F Vogel's avatar
      [PATCH] check nmi watchdog is broken · 67701ae9
      Jack F Vogel authored
      A bug against an xSeries system showed up recently noting that the
      check_nmi_watchdog() test was failing.
      I have been investigating it and discovered in both i386 and x86_64 the
      recent change to the routine to use the cpu_callin_map has uncovered a
      problem.  Prior to that change, on an SMP box, the test was trivally
      passing because all cpu's were found to not yet be online, but now with the
      callin_map they are discovered, it goes on to test the counter and they
      have not yet begun to increment, so it announces a CPU is stuck and bails
      On all the systems I have access to test, the announcement of failure is
      also bougs...  by the time you can login and check /proc/interrupts, the
      NMI count is happily incrementing on all CPUs.  Its just that the test is
      being done too early.
      I have tried moving the call to the test around a bit, and it was always
      too early.  I finally hit on this proposed solution, it delays the routine
      via a late_initcall(), seems like the right solution to me.
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  17. 16 Apr, 2005 2 commits