1. 27 9月, 2007 1 次提交
    • T
      x86-64: Disable local APIC timer use on AMD systems with C1E · e66485d7
      Thomas Gleixner 提交于
      commit 3556ddfa titled
      
       [PATCH] x86-64: Disable local APIC timer use on AMD systems with C1E
      
      solves a problem with AMD dual core laptops e.g. HP nx6325 (Turion 64
      X2) with C1E enabled:
      
      When both cores go into idle at the same time, then the system switches
      into C1E state, which is basically the same as C3. This stops the local
      apic timer.
      
      This was debugged right after the dyntick merge on i386 and despite the
      patch title it fixes only the 32 bit path.
      
      x86_64 is still missing this fix. It seems that mainline is not really
      affected by this issue, as the PIT is running and keeps jiffies
      incrementing, but that's just waiting for trouble.
      
      -mm suffers from this problem due to the x86_64 high resolution timer
      patches.
      
      This is a quick and dirty port of the i386 code to x86_64.
      
      I spent quite a time with Rafael to debug the -mm / hrt wreckage until
      someone pointed us to this. I really had forgotten that we debugged this
      half a year ago already.
      
      Sigh, is it just me or is there something yelling arch/x86 into my ear?
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e66485d7
  2. 22 7月, 2007 2 次提交
  3. 03 5月, 2007 2 次提交
    • F
      [PATCH] x86-64: safe_apic_wait_icr_idle - x86_64 · 8339e9fb
      Fernando Luis VazquezCao 提交于
      apic_wait_icr_idle looks like this:
      
      static __inline__ void apic_wait_icr_idle(void)
      {
        while (apic_read(APIC_ICR) & APIC_ICR_BUSY)
          cpu_relax();
      }
      
      The busy loop in this function would not be problematic if the
      corresponding status bit in the ICR were always updated, but that does
      not seem to be the case under certain crash scenarios. Kdump uses an IPI
      to stop the other CPUs in the event of a crash, but when any of the
      other CPUs are locked-up inside the NMI handler the CPU that sends the
      IPI will end up looping forever in the ICR check, effectively
      hard-locking the whole system.
      
      Quoting from Intel's "MultiProcessor Specification" (Version 1.4), B-3:
      
      "A local APIC unit indicates successful dispatch of an IPI by
      resetting the Delivery Status bit in the Interrupt Command
      Register (ICR). The operating system polls the delivery status
      bit after sending an INIT or STARTUP IPI until the command has
      been dispatched.
      
      A period of 20 microseconds should be sufficient for IPI dispatch
      to complete under normal operating conditions. If the IPI is not
      successfully dispatched, the operating system can abort the
      command. Alternatively, the operating system can retry the IPI by
      writing the lower 32-bit double word of the ICR. This “time-out”
      mechanism can be implemented through an external interrupt, if
      interrupts are enabled on the processor, or through execution of
      an instruction or time-stamp counter spin loop."
      
      Intel's documentation suggests the implementation of a time-out
      mechanism, which, by the way, is already being open-coded in some parts
      of the kernel that tinker with ICR.
      
      Create a apic_wait_icr_idle replacement that implements the time-out
      mechanism and that can be used to solve the aforementioned problem.
      
      AK: moved both functions out of line
      AK: Added improved loop from Keith Owens
      Signed-off-by: NFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      8339e9fb
    • I
      [PATCH] x86: default to physical mode on hotplug CPU kernels · 3c43f039
      Ingo Molnar 提交于
      Default to physical mode on hotplug CPU kernels.  Furher simplify and clean up
      the APIC initialization code.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: "Li, Shaohua" <shaohua.li@intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      3c43f039
  4. 24 3月, 2007 1 次提交
  5. 05 10月, 2006 1 次提交
    • D
      IRQ: Maintain regs pointer globally rather than passing to IRQ handlers · 7d12e780
      David Howells 提交于
      Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
      of passing regs around manually through all ~1800 interrupt handlers in the
      Linux kernel.
      
      The regs pointer is used in few places, but it potentially costs both stack
      space and code to pass it around.  On the FRV arch, removing the regs parameter
      from all the genirq function results in a 20% speed up of the IRQ exit path
      (ie: from leaving timer_interrupt() to leaving do_IRQ()).
      
      Where appropriate, an arch may override the generic storage facility and do
      something different with the variable.  On FRV, for instance, the address is
      maintained in GR28 at all times inside the kernel as part of general exception
      handling.
      
      Having looked over the code, it appears that the parameter may be handed down
      through up to twenty or so layers of functions.  Consider a USB character
      device attached to a USB hub, attached to a USB controller that posts its
      interrupts through a cascaded auxiliary interrupt controller.  A character
      device driver may want to pass regs to the sysrq handler through the input
      layer which adds another few layers of parameter passing.
      
      I've build this code with allyesconfig for x86_64 and i386.  I've runtested the
      main part of the code on FRV and i386, though I can't test most of the drivers.
      I've also done partial conversion for powerpc and MIPS - these at least compile
      with minimal configurations.
      
      This will affect all archs.  Mostly the changes should be relatively easy.
      Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
      
      	struct pt_regs *old_regs = set_irq_regs(regs);
      
      And put the old one back at the end:
      
      	set_irq_regs(old_regs);
      
      Don't pass regs through to generic_handle_irq() or __do_IRQ().
      
      In timer_interrupt(), this sort of change will be necessary:
      
      	-	update_process_times(user_mode(regs));
      	-	profile_tick(CPU_PROFILING, regs);
      	+	update_process_times(user_mode(get_irq_regs()));
      	+	profile_tick(CPU_PROFILING);
      
      I'd like to move update_process_times()'s use of get_irq_regs() into itself,
      except that i386, alone of the archs, uses something other than user_mode().
      
      Some notes on the interrupt handling in the drivers:
      
       (*) input_dev() is now gone entirely.  The regs pointer is no longer stored in
           the input_dev struct.
      
       (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking.  It does
           something different depending on whether it's been supplied with a regs
           pointer or not.
      
       (*) Various IRQ handler function pointers have been moved to type
           irq_handler_t.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
      7d12e780
  6. 26 9月, 2006 3 次提交
    • A
      [PATCH] Don't access the APIC in safe_smp_processor_id when it is not mapped yet · b7f5e3c7
      Andi Kleen 提交于
      Lockdep can call the dwarf2 unwinder early, and the dwarf2 code
      uses safe_smp_processor_id which tries to access the local APIC page.
      But that doesn't work before the APIC code has set up its fixmap.
      
      Check for this case and always return boot cpu then.
      
      Cc: jbeulich@novell.com
      Cc: mingo@elte.hu
      Signed-off-by: NAndi Kleen <ak@suse.de>
      b7f5e3c7
    • A
      [PATCH] Convert x86-64 to early param · 2c8c0e6b
      Andi Kleen 提交于
      Instead of hackish manual parsing
      
      Requires earlier i386 patchkit, but also fixes i386 early_printk again.
      
      I removed some obsolete really early parameters which didn't do anything useful.
      Also made a few parameters that needed it early (mostly oops printing setup)
      
      Also removed one panic check that wasn't visible without
      early console anyways (the early console is now initialized after that
      panic)
      
      This cleans up a lot of code.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      2c8c0e6b
    • A
      [PATCH] Remove all ifdefs for local/io apic · 7f11d8a5
      Andi Kleen 提交于
      IO-APIC or local APIC can only be disabled at runtime anyways and
      Kconfig has forced these options on for a long time now.
      
      The Kconfigs are kept only now for the benefit of the shared acpi
      boot.c code.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      7f11d8a5
  7. 27 6月, 2006 3 次提交
  8. 26 4月, 2006 1 次提交
  9. 05 2月, 2006 1 次提交
    • A
      [PATCH] x86_64: Allow to run main time keeping from the local APIC interrupt · 73dea47f
      Andi Kleen 提交于
      Another piece from the no-idle-tick patch.
      
      This can be enabled with the "apicmaintimer" option.
      
      This is mainly useful when the PIT/HPET interrupt is unreliable.
      Note there are some systems that are known to stop the APIC
      timer in C3. For those it will never work, but this case
      should be automatically detected.
      
      It also only works with PM timer right now. When HPET is used
      the way the main timer handler computes the delay doesn't work.
      
      It should be a bit more efficient because there is one less
      regular interrupt to process on the boot processor.
      
      Requires earlier bugfix from Venkatesh
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      73dea47f
  10. 12 1月, 2006 3 次提交
  11. 15 11月, 2005 1 次提交
    • J
      [PATCH] x86_64: Support for AMD specific MCE Threshold. · 89b831ef
      Jacob Shin 提交于
      MC4_MISC - DRAM Errors Threshold Register realized under AMD K8 Rev F.
      This register is used to count correctable and uncorrectable ECC errors that occur during DRAM read operations.
      The user may interface through sysfs files in order to change the threshold configuration.
      
      bank%d/error_count - reads current error count, write to clear.
      bank%d/interrupt_enable - set/clear interrupt enable.
      bank%d/threshold_limit - read/write the threshold limit.
      
      APIC vector 0xF9 in hw_irq.h.
      5 software defined bank ids in mce.h.
      new apic.c function to setup threshold apic lvt.
      defaults to interrupt off, count enabled, and threshold limit max.
      sysfs interface created on /sys/devices/system/threshold.
      
      AK: added some ifdefs to make it compile on UP
      Signed-off-by: NJacob Shin <jacob.shin@amd.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      89b831ef
  12. 13 9月, 2005 2 次提交
  13. 26 6月, 2005 1 次提交
  14. 01 5月, 2005 1 次提交
    • J
      [PATCH] check nmi watchdog is broken · 67701ae9
      Jack F Vogel 提交于
      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
      out.
      
      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: NAdrian Bunk <bunk@stusta.de>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      67701ae9
  15. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4