1. 24 4月, 2007 1 次提交
    • A
      [PATCH] x86: Remove noreplacement option · 9ce883be
      Andi Kleen 提交于
      noreplacement is dangerous on modern systems because it will not replace the
      context switch FNSAVE with SSE aware FXSAVE. But other places in the kernel still assume
      SSE and do FXSAVE and the CPU will then access FXSAVE information with
      FNSAVE and cause corruption.
      
      Easiest way to avoid this is to remove the option. It was mostly for paranoia
      reasons anyways and alternative()s have been stable for some time.
      
      Thanks to Jeremy F. for reporting and helping debug it.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      9ce883be
  2. 13 2月, 2007 2 次提交
  3. 09 1月, 2007 1 次提交
  4. 07 12月, 2006 2 次提交
  5. 04 10月, 2006 1 次提交
  6. 30 9月, 2006 2 次提交
  7. 26 9月, 2006 1 次提交
  8. 29 7月, 2006 1 次提交
  9. 27 6月, 2006 1 次提交
    • J
      [PATCH] x86_64: Calgary IOMMU - Calgary specific bits · e465058d
      Jon Mason 提交于
      This patch hooks Calgary into the build, the x86-64 IOMMU
      initialization paths, and introduces the Calgary specific bits.  The
      implementation draws inspiration from both PPC (which has support for
      the same chip but requires firmware support which we don't have on
      x86-64) and gart. Calgary is different from gart in that it support a
      translation table per PHB, as opposed to the single gart aperture.
      
      Changes from previous version:
       * Addition of boot-time disablement for bus-level translation/isolation
         (e.g, enable userspace DMA for things like X)
       * Usage of newer IOMMU abstraction functions
      Signed-off-by: NMuli Ben-Yehuda <muli@il.ibm.com>
      Signed-off-by: NJon Mason <jdmason@us.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e465058d
  10. 10 4月, 2006 1 次提交
    • A
      [PATCH] x86_64: Reserve SRAT hotadd memory on x86-64 · 68a3a7fe
      Andi Kleen 提交于
      From: Keith Mannthey, Andi Kleen
      
      Implement memory hotadd without sparsemem. The memory in the SRAT
      hotadd area is just preserved instead and can be activated later.
      
      There are a few restrictions:
      - Only one continuous hotadd area allowed per node
      
      The main problem is dealing with the many buggy SRAT tables
      that are out there. The strategy here is to reject anything
      suspicious.
      
      Originally from Keith Mannthey, with several hacks and changes by AK
      and also contributions from Andrew Morton
      
      [ TBD: Problems pointed out by KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>:
      
       1) Goto's rebuild_zonelist patch will not work if CONFIG_MEMORY_HOTPLUG=n.
      
          Rebuilding zonelist is necessary when the system has just memory <
          4G at boot, and hot add memory > 4G.  because x86_64 has DMA32,
          ZONE_NORAML is not included into zonelist at boot time if system
          doesn't have memory >4G at boot.
      
          [AK: should just force the higher zones at boot time when SRAT tells us]
      
       2) zone and node's spanned_pages and present_pages are not incremented.
          They should be.
      
          For example, our server (ia64/Fujitsu PrimeQuest) can equip memory
          from 4G to 1T(maybe 2T in future), and SRAT will *always* say we have
          possible 1T +memory.  (Microsoft requires "write all possible memory
          in SRAT") When we reserve memmap for possible 1T memory, Linux will
          not work well in +minimum 4G configuraion ;)
      
          [AK: needs limiting to 5-10% of max memory]
       ]
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      68a3a7fe
  11. 27 2月, 2006 1 次提交
    • A
      [PATCH] x86_64: Better ATI timer fix · ab9b32ee
      Andi Kleen 提交于
      The previous experiment for using apicmaintimer on ATI systems didn't
      work out very well.  In particular laptops with C2/C3 support often
      don't let it tick during idle, which makes it useless.  There were also
      some other bugs that made the apicmaintimer often not used at all.
      
      I tried some other experiments - running timer over RTC and some other
      things but they didn't really work well neither.
      
      I rechecked the specs now and it turns out this simple change is
      actually enough to avoid the double ticks on the ATI systems.  We just
      turn off IRQ 0 in the 8254 and only route it directly using the IO-APIC.
      
      I tested it on a few ATI systems and it worked there.  In fact it worked
      on all chipsets (NVidia, Intel, AMD, ATI) I tried it on.
      
      According to the ACPI spec routing should always work through the
      IO-APIC so I think it's the correct thing to do anyways (and most of the
      old gunk in check_timer should be thrown away for x86-64).
      
      But for 2.6.16 it's best to do a fairly minimal change:
       - Use the known to be working everywhere-but-ATI IRQ0 both over 8254
         and IO-APIC setup everywhere
       - Except on ATI disable IRQ0 in the 8254
       - Remove the code to select apicmaintimer on ATI chipsets
       - Add some boot options to allow to override this (just paranoia)
      
      In 2.6.17 I hope to switch the default over to this for everybody.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ab9b32ee
  12. 05 2月, 2006 2 次提交
    • A
      [PATCH] x86_64: Calibrate APIC timer using PM timer · 0c3749c4
      Andi Kleen 提交于
      On some broken motherboards (at least one NForce3 based AMD64 laptop)
      the PIT timer runs at a incorrect frequency.  This patch adds a new
      option "apicpmtimer" that allows to use the APIC timer and calibrate it
      using the PMTimer.  It requires the earlier patch that allows to run the
      main timer from the APIC.
      
      Specifying apicpmtimer implies apicmaintimer.
      
      The option defaults to off for now.
      
      I tested it on a few systems and the resulting APIC timer frequencies
      were usually a bit off, but always <1%, which should be tolerable.
      
      TBD figure out heuristic to enable this automatically on the affected
      systems TBD perhaps do it on all NForce3s or using DMI?
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0c3749c4
    • 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
  13. 15 1月, 2006 1 次提交
  14. 12 1月, 2006 1 次提交
  15. 15 11月, 2005 3 次提交
    • A
      [PATCH] x86_64: Remove CONFIG_CHECKING and add command line option for pagefault tracing · 9e43e1b7
      Andi Kleen 提交于
      CONFIG_CHECKING covered some debugging code used in the early times
      of the port. But it wasn't even SMP safe for quite some time
      and the bugs it checked for seem to be gone.
      
      This patch removes all the code to verify GS at kernel entry. There
      haven't been any new bugs in this area for a long time.
      
      Previously it also covered the sysctl for the page fault tracing.
      That didn't make much sense because that code was unconditionally
      compiled in. I made that a boot option now because it is typically
      only useful at boot.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9e43e1b7
    • A
      [PATCH] x86_64: Log machine checks from boot on Intel systems · e583538f
      Andi Kleen 提交于
      The logging for boot errors was turned off because it was broken
      on some AMD systems. But give Intel EM64T systems a chance because they are
      supposed to be correct there.
      
      The advantage is that there is a chance to actually log uncorrected
      machine checks after the reset.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e583538f
    • A
      [PATCH] x86_64: New heuristics to find out hotpluggable CPUs. · 420f8f68
      Andi Kleen 提交于
      With a NR_CPUS==128 kernel with CPU hotplug enabled we would waste 4MB
      on per CPU data of all possible CPUs.  The reason was that HOTPLUG
      always set up possible map to NR_CPUS cpus and then we need to allocate
      that much (each per CPU data is roughly ~32k now)
      
      The underlying problem is that ACPI didn't tell us how many hotplug CPUs
      the platform supports.  So the old code just assumed all, which would
      lead to this memory wastage.
      
      This implements some new heuristics:
      
       - If the BIOS specified disabled CPUs in the ACPI/mptables assume they
         can be enabled later (this is bending the ACPI specification a bit,
         but seems like a obvious extension)
       - The user can overwrite it with a new additionals_cpus=NUM option
       - Otherwise use half of the available CPUs or 2, whatever is more.
      
      Cc: ashok.raj@intel.com
      Cc: len.brown@intel.com
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      420f8f68
  16. 13 9月, 2005 1 次提交
  17. 08 8月, 2005 1 次提交
  18. 29 7月, 2005 1 次提交
  19. 21 5月, 2005 1 次提交
  20. 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