1. 20 8月, 2008 1 次提交
    • S
      x86: fix "kernel won't boot on a Cyrix MediaGXm (Geode)" · c6744955
      Samuel Sieb 提交于
      Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B has stopped
      booting starting at v2.6.22.
      
      The reason is this commit:
      
      > commit f25f64ed
      > Author: Juergen Beisert <juergen@kreuzholzen.de>
      > Date:   Sun Jul 22 11:12:38 2007 +0200
      >
      >     x86: Replace NSC/Cyrix specific chipset access macros by inlined functions.
      
      this commit activated a macro which was dormant before due to (buggy)
      macro side-effects.
      
      I've looked through various datasheets and found that the GXm and GXLV
      Geode processors don't have an incrementor.
      
      Remove the incrementor setup entirely.  As the incrementor value
      differs according to clock speed and we would hope that the BIOS
      configures it correctly, it is probably the right solution.
      
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c6744955
  2. 15 8月, 2008 1 次提交
  3. 09 8月, 2008 4 次提交
  4. 01 8月, 2008 1 次提交
    • K
      x86: fdiv bug detection fix · e0d22d03
      Krzysztof Helt 提交于
      The fdiv detection code writes s32 integer into
      the boot_cpu_data.fdiv_bug.
      However, the boot_cpu_data.fdiv_bug is only char (s8)
      field so the detection overwrites already set fields for
      other bugs, e.g. the f00f bug field.
      
      Use local s32 variable to receive result.
      
      This is a partial fix to Bugzilla #9928  - fixes wrong
      information about the f00f bug (tested) and probably
      for coma bug (I have no cpu to test this).
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e0d22d03
  5. 26 7月, 2008 1 次提交
  6. 22 7月, 2008 3 次提交
  7. 21 7月, 2008 2 次提交
  8. 20 7月, 2008 3 次提交
  9. 19 7月, 2008 5 次提交
  10. 18 7月, 2008 2 次提交
    • A
      x86, intel_cacheinfo: fix use-after-free cache_kobject · 8b2b9c1a
      Akinobu Mita 提交于
      This avoids calling kobject_uevent() with cache_kobject that has
      already been deallocated in an error path.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8b2b9c1a
    • M
      x86: APIC: remove apic_write_around(); use alternatives · 593f4a78
      Maciej W. Rozycki 提交于
      Use alternatives to select the workaround for the 11AP Pentium erratum
      for the affected steppings on the fly rather than build time.  Remove the
      X86_GOOD_APIC configuration option and replace all the calls to
      apic_write_around() with plain apic_write(), protecting accesses to the
      ESR as appropriate due to the 3AP Pentium erratum.  Remove
      apic_read_around() and all its invocations altogether as not needed.
      Remove apic_write_atomic() and all its implementing backends.  The use of
      ASM_OUTPUT2() is not strictly needed for input constraints, but I have
      used it for readability's sake.
      
      I had the feeling no one else was brave enough to do it, so I went ahead
      and here it is.  Verified by checking the generated assembly and tested
      with both a 32-bit and a 64-bit configuration, also with the 11AP
      "feature" forced on and verified with gdb on /proc/kcore to work as
      expected (as an 11AP machines are quite hard to get hands on these days).
      Some script complained about the use of "volatile", but apic_write() needs
      it for the same reason and is effectively a replacement for writel(), so I
      have disregarded it.
      
      I am not sure what the policy wrt defconfig files is, they are generated
      and there is risk of a conflict resulting from an unrelated change, so I
      have left changes to them out.  The option will get removed from them at
      the next run.
      
      Some testing with machines other than mine will be needed to avoid some
      stupid mistake, but despite its volume, the change is not really that
      intrusive, so I am fairly confident that because it works for me, it will
      everywhere.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      593f4a78
  11. 16 7月, 2008 2 次提交
  12. 14 7月, 2008 1 次提交
    • Y
      x86: get x86_phys_bits early · 87a1c441
      Yinghai Lu 提交于
      when try to make hpet_enable use io_remap instead fixmap got
      
      ioremap: invalid physical address fed00000
      ------------[ cut here ]------------
      WARNING: at arch/x86/mm/ioremap.c:161 __ioremap_caller+0x8c/0x2f3()
      Modules linked in:
      Pid: 0, comm: swapper Not tainted 2.6.26-rc9-tip-01873-ga9827e7-dirty #358
      
      Call Trace:
       [<ffffffff8026615e>] warn_on_slowpath+0x6c/0xa7
       [<ffffffff802e2313>] ? __slab_alloc+0x20a/0x3fb
       [<ffffffff802d85c5>] ? mpol_new+0x88/0x17d
       [<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
       [<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
       [<ffffffff8024b0d2>] __ioremap_caller+0x8c/0x2f3
       [<ffffffff80e86dbd>] ? hpet_enable+0x39/0x241
       [<ffffffff8022a4f4>] ? mcount_call+0x5/0x31
       [<ffffffff8024b466>] ioremap_nocache+0x2a/0x40
       [<ffffffff80e86dbd>] hpet_enable+0x39/0x241
       [<ffffffff80e7a1f6>] hpet_time_init+0x21/0x4e
       [<ffffffff80e730e9>] start_kernel+0x302/0x395
       [<ffffffff80e722aa>] x86_64_start_reservations+0xb9/0xd4
       [<ffffffff80e722fe>] ? x86_64_init_pda+0x39/0x4f
       [<ffffffff80e72400>] x86_64_start_kernel+0xec/0x107
      
      ---[ end trace a7919e7f17c0a725 ]---
      
      it seems for amd system that is set later...
      try to move setting early in early_identify_cpu.
      and remove same code for intel and centaur.
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      87a1c441
  13. 13 7月, 2008 2 次提交
  14. 11 7月, 2008 2 次提交
  15. 08 7月, 2008 10 次提交