1. 17 10月, 2007 1 次提交
    • M
      x86: Convert cpu_core_map to be a per cpu variable · 08357611
      Mike Travis 提交于
      This is from an earlier message from 'Christoph Lameter':
      
          cpu_core_map is currently an array defined using NR_CPUS. This means that
          we overallocate since we will rarely really use maximum configured cpu.
      
          If we put the cpu_core_map into the per cpu area then it will be allocated
          for each processor as it comes online.
      
          This means that the core map cannot be accessed until the per cpu area
          has been allocated. Xen does a weird thing here looping over all processors
          and zeroing the masks that are not yet allocated and that will be zeroed
          when they are allocated. I commented the code out.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      08357611
  2. 14 10月, 2007 1 次提交
    • D
      Delete filenames in comments. · 835c34a1
      Dave Jones 提交于
      Since the x86 merge, lots of files that referenced their own filenames
      are no longer correct.  Rather than keep them up to date, just delete
      them, as they add no real value.
      
      Additionally:
      - fix up comment formatting in scx200_32.c
      - Remove a credit from myself in setup_64.c from a time when we had no SCM
      - remove longwinded history from tsc_32.c which can be figured out from
        git.
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      835c34a1
  3. 13 10月, 2007 1 次提交
  4. 11 10月, 2007 2 次提交
  5. 27 9月, 2007 2 次提交
    • L
      Revert "x86-64: Disable local APIC timer use on AMD systems with C1E" · f7f847b0
      Linus Torvalds 提交于
      This reverts commit e66485d7, since
      Rafael Wysocki noticed that the change only works for his in -mm, not in
      mainline (and that both "noapictimer" _and_ "apicmaintimer" are broken
      on his hardware, but that's apparently not a regression, just a symptom
      of the same issue that causes the automatic apic timer disable to not
      work).
      
      It turns out that it really doesn't work correctly on x86-64, since
      x86-64 doesn't use the generic clock events for timers yet.
      
      Thanks to Rafal for testing, and here's the ugly details on x86-64 as
      per Thomas:
      
        "I just looked into the code and the logic vs.  noapictimer on SMP is
         completely broken.
      
         On i386 the noapictimer option not only disables the local APIC
         timer, it also registers the CPUs for broadcasting via IPI on SMP
         systems.
      
         The x86-64 code uses the broadcast only when the local apic timer is
         active, i.e.  "noapictimer" is not on the command line.  This defeats
         the whole purpose of "noapictimer".  It should be there to make boxen
         work, where the local APIC timer actually has a hardware problem,
         e.g.  the nx6325.
      
         The current implementation of x86_64 only fixes the ACPI c-states
         related problem where the APIC timer stops in C3(2), nothing else.
      
         On nx6325 and other AMD X2 equipped systems which have the C1E
         enabled we run into the following:
      
         PIT keeps jiffies (and the system) running, but the local APIC timer
         interrupts can get out of sync due to this C1E effect.
      
         I don't think this is a critical problem, but it is wrong
         nevertheless.
      
         I think it's safe to revert the C1E patch and postpone the fix to the
         clock events conversion."
      
      On further reflection, Thomas noted:
      
         "It's even worse than I thought on the first check:
      
          "noapictimer" on the command line of an SMP box prevents _ONLY_ the
          boot CPU apic timer from being used.  But the secondary CPU is still
          unconditionally setting up the APIC timer and uses the non
          calibrated variable calibration_result, which is of course 0, to
          setup the APIC timer.  Wreckage guaranteed."
      
      so we'll just have to wait for the x86 merge to hopefully fix this up
      for x86-64.
      Tested-and-requested-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f7f847b0
    • 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
  6. 30 7月, 2007 1 次提交
  7. 25 7月, 2007 1 次提交
  8. 23 7月, 2007 1 次提交
  9. 22 7月, 2007 2 次提交
  10. 13 7月, 2007 2 次提交
  11. 12 5月, 2007 1 次提交
  12. 07 5月, 2007 1 次提交
    • L
      Revert "[PATCH] x86: __pa and __pa_symbol address space separation" · e3ebadd9
      Linus Torvalds 提交于
      This was broken.  It adds complexity, for no good reason.  Rather than
      separate __pa() and __pa_symbol(), we should deprecate __pa_symbol(),
      and preferably __pa() too - and just use "virt_to_phys()" instead, which
      is more readable and has nicer semantics.
      
      However, right now, just undo the separation, and make __pa_symbol() be
      the exact same as __pa().  That fixes the bugs this patch introduced,
      and we can do the fairly obvious cleanups later.
      
      Do the new __phys_addr() function (which is now the actual workhorse for
      the unified __pa()/__pa_symbol()) as a real external function, that way
      all the potential issues with compile/link-time optimizations of
      constant symbol addresses go away, and we can also, if we choose to, add
      more sanity-checking of the argument.
      
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e3ebadd9
  13. 03 5月, 2007 6 次提交
  14. 13 2月, 2007 5 次提交
  15. 08 12月, 2006 1 次提交
  16. 07 12月, 2006 4 次提交
  17. 30 9月, 2006 1 次提交
  18. 27 9月, 2006 1 次提交
  19. 26 9月, 2006 6 次提交