1. 31 12月, 2008 2 次提交
  2. 22 9月, 2008 1 次提交
  3. 22 8月, 2008 2 次提交
    • I
      x86: work around MTRR mask setting, v2 · 9754a5b8
      Ingo Molnar 提交于
      improve the debug printout:
      
      - make it actually display something
      - print it only once
      
      would be nice to have a WARN_ONCE() facility, to feed such things to
      kerneloops.org.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9754a5b8
    • Y
      x86: work around MTRR mask setting · 38cc1c3d
      Yinghai Lu 提交于
      Joshua Hoblitt reported that only 3 GB of his 16 GB of RAM is
      usable. Booting with mtrr_show showed us the BIOS-initialized
      MTRR settings - which are all wrong.
      
      So the root cause is that the BIOS has not set the mask correctly:
      
      >               [    0.429971]  MSR00000200: 00000000d0000000
      >               [    0.433305]  MSR00000201: 0000000ff0000800
      > should be ==> [    0.433305]  MSR00000201: 0000003ff0000800
      >
      >               [    0.436638]  MSR00000202: 00000000e0000000
      >               [    0.439971]  MSR00000203: 0000000fe0000800
      > should be ==> [    0.439971]  MSR00000203: 0000003fe0000800
      >
      >               [    0.443304]  MSR00000204: 0000000000000006
      >               [    0.446637]  MSR00000205: 0000000c00000800
      > should be ==> [    0.446637]  MSR00000205: 0000003c00000800
      >
      >               [    0.449970]  MSR00000206: 0000000400000006
      >               [    0.453303]  MSR00000207: 0000000fe0000800
      > should be ==> [    0.453303]  MSR00000207: 0000003fe0000800
      >
      >               [    0.456636]  MSR00000208: 0000000420000006
      >               [    0.459970]  MSR00000209: 0000000ff0000800
      > should be ==> [    0.459970]  MSR00000209: 0000003ff0000800
      
      So detect this borkage and add the prefix 111.
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      38cc1c3d
  4. 25 5月, 2008 4 次提交
  5. 29 4月, 2008 1 次提交
  6. 17 4月, 2008 3 次提交
  7. 27 3月, 2008 1 次提交
  8. 30 1月, 2008 3 次提交
    • J
      x86, 32-bit: trim memory not covered by wb mtrrs · 99fc8d42
      Jesse Barnes 提交于
      On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all
      available RAM, meaning the last few megs (or even gigs) of memory will be
      marked uncached.  Since Linux tends to allocate from high memory addresses
      first, this causes the machine to be unusably slow as soon as the kernel
      starts really using memory (i.e.  right around init time).
      
      This patch works around the problem by scanning the MTRRs at boot and
      figuring out whether the current end_pfn value (setup by early e820 code)
      goes beyond the highest WB MTRR range, and if so, trimming it to match.  A
      fairly obnoxious KERN_WARNING is printed too, letting the user know that
      not all of their memory is available due to a likely BIOS bug.
      
      Something similar could be done on i386 if needed, but the boot ordering
      would be slightly different, since the MTRR code on i386 depends on the
      boot_cpu_data structure being setup.
      
      This patch fixes a bug in the last patch that caused the code to run on
      non-Intel machines (AMD machines apparently don't need it and it's untested
      on other non-Intel machines, so best keep it off).
      
      Further enhancements and fixes from:
      
        Yinghai Lu <Yinghai.Lu@Sun.COM>
        Andi Kleen <ak@suse.de>
      Signed-off-by: NJesse Barnes <jesse.barnes@intel.com>
      Tested-by: NJustin Piszcz <jpiszcz@lucidpixels.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      99fc8d42
    • D
      x86: use CR0 defines. · 7ebad705
      Dave Jones 提交于
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7ebad705
    • P
      x86: mtrr use type bool [RESEND AGAIN] · 2d2ee8de
      Paul Jimenez 提交于
      This is a janitorish patch to 1) remove private TRUE/FALSE #def's in
      favor of using the standard enum from linux/stddef.h and 2) switch the
      variables holding those values to type 'bool' (from linux/types.h)
      since it both seems more appropriate and allows for potentially better
      optimization.
      
      As a truly minor aside, I removed a couple of comments documenting
      a 'do_safe' parameter that seems to no longer exist.
      Signed-off-by: NPaul Jimenez <pj@place.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      2d2ee8de
  9. 20 10月, 2007 1 次提交
  10. 11 10月, 2007 1 次提交
  11. 22 7月, 2007 1 次提交
    • S
      i386: fix section mismatch warnings in mtrr · 9ef231a4
      Sam Ravnborg 提交于
      Following section mismatch warnings were reported by Andrey Borzenkov:
      
      WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text:amd_init_mtrr from .text between 'mtrr_bp_init' (at offset 0x967a) and 'mtrr_attrib_to_str'
      WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text:cyrix_init_mtrr from .text between 'mtrr_bp_init' (at offset 0x967f) and 'mtrr_attrib_to_str'
      WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text:centaur_init_mtrr from .text between 'mtrr_bp_init' (at offset 0x9684) and 'mtrr_attrib_to_str'
      WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text: from .text between 'get_mtrr_state' (at offset 0xa735) and 'generic_get_mtrr'
      WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text: from .text between 'get_mtrr_state' (at offset 0xa749) and 'generic_get_mtrr'
      WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text: from .text between 'get_mtrr_state' (at offset 0xa770) and 'generic_get_mtrr'
      
      It was tracked down to a few functions missing __init tag.
      Compile tested only.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9ef231a4
  12. 02 7月, 2007 2 次提交
    • A
      i386: mtrr crash fix · 84288ad8
      Andrew Morton 提交于
      Commit 3ebad590 ("[PATCH] x86: Save and
      restore the fixed-range MTRRs of the BSP when suspending") added mtrr
      operations without verifying that the CPU has MTRRs.  Crashes transmeta
      CPUs.
      
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <linux@horizon.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      84288ad8
    • L
      i386: remove bogus mtrr range check · 4710bcce
      Linus Torvalds 提交于
      Commit 9215da33 "fixed" the MTRR range
      check to not allow any MTRR's under the 1MB mark (since that's where the
      fixed MTRR's are active).
      
      However, that was totally bogus, since it's normal (and almost required)
      to have a large variable MTRR that starts at 0, and covers some large
      percentage of the whole RAM, and then using the fixed MTRR's to override
      that large MTRR to handle the special ISA hole in the 640k-1M region.
      
      The old check was bogus too (checking that no variable MTRR is used that
      is entirely under the 1MB range), but at least it wasn't actively
      detrimental, because no sane situation would ever trigger such MTRR
      usage in the first place.
      
      That said, the whole notion of not allowing variable MTRR's in the low
      1MB is just stupid, so rather than revert the commit, this just removes
      the whole sad and unnecessary check entirely.
      
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Tested-by: NLuca Palermo <darkmage@sabayonlinux.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4710bcce
  13. 21 6月, 2007 1 次提交
  14. 17 5月, 2007 1 次提交
  15. 03 5月, 2007 4 次提交
    • R
      [PATCH] i386: fix mtrr sections · 25c16b99
      Randy Dunlap 提交于
      Fix section mismatch warnings in mtrr code.
      Fix line length on one source line.
      
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x103)
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x180)
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x199)
      WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x1c1)
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      25c16b99
    • B
      [PATCH] i386: Enable support for fixed-range IORRs to keep RdMem & WrMem in sync · de938c51
      Bernhard Kaindl 提交于
      If our copy of the MTRRs of the BSP has RdMem or WrMem set, and
      we are running on an AMD64/K8 system, the boot CPU must have had
      MtrrFixDramEn and MtrrFixDramModEn set (otherwise our RDMSR would
      have copied these bits cleared), so we set them on this CPU as well.
      
      This allows us to keep the AMD64/K8 RdMem and WrMem bits in sync
      across the CPUs of SMP systems in order to fullfill the duty of
      system software to "initialize and maintain MTRR consistency
      across all processors." as written in the AMD and Intel manuals.
      
      If an WRMSR instruction fails because MtrrFixDramModEn is not
      set, I expect that also the Intel-style MTRR bits are not updated.
      
      AK: minor cleanup, moved MSR defines around
      Signed-off-by: NBernhard Kaindl <bk@suse.de>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      de938c51
    • B
      [PATCH] x86: Adds mtrr_save_fixed_ranges() for use in two later patches. · 2b3b4835
      Bernhard Kaindl 提交于
      In this current implementation which is used in other patches,
      mtrr_save_fixed_ranges() accepts a dummy void pointer because
      in the current implementation of one of these patches, this
      function may be called from smp_call_function_single() which
      requires that this function takes a void pointer argument.
      
      This function calls get_fixed_ranges(), passing mtrr_state.fixed_ranges
      which is the element of the static struct which stores our current
      backup of the fixed-range MTRR values which all CPUs shall be
      using.
      
      Because  mtrr_save_fixed_ranges calls get_fixed_ranges after
      kernel initialisation time, __init needs to be removed from
      the declaration of get_fixed_ranges().
      
      If CONFIG_MTRR is not set, we define mtrr_save_fixed_ranges
      as an empty statement because there is nothing to do.
      
      AK: Moved prototypes for x86-64 around to fix warnings
      Signed-off-by: NBernhard Kaindl <bk@suse.de>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      2b3b4835
    • J
      [PATCH] i386: mtrr range check correction · 9215da33
      Jan Beulich 提交于
      Whether a region is below 1Mb is determined by its start rather than
      its end.
      
      This hunk got erroneously dropped from a previous patch.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      9215da33
  16. 07 12月, 2006 2 次提交
    • J
      [PATCH] i386: fix MTRR code · 365bff80
      Jan Beulich 提交于
      Until not so long ago, there were system log messages pointing to
      inconsistent MTRR setup of the video frame buffer caused by the way vesafb
      and X worked. While vesafb was fixed meanwhile, I believe fixing it there
      only hides a shortcoming in the MTRR code itself, in that that code is not
      symmetric with respect to the ordering of attempts to set up two (or more)
      regions where one contains the other. In the current shape, it permits
      only setting up sub-regions of pre-exisiting ones. The patch below makes
      this symmetric.
      
      While working on that I noticed a few more inconsistencies in that code,
      namely
      - use of 'unsigned int' for sizes in many, but not all places (the patch
        is converting this to use 'unsigned long' everywhere, which specifically
        might be necessary for x86-64 once a processor supporting more than 44
        physical address bits would become available)
      - the code to correct inconsistent settings during secondary processor
        startup tried (if necessary) to correct, among other things, the value
        in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
        used (i.e. stored in the respective MSR)
      - the generic range validation code checked that the end of the
        to-be-added range would be above 1MB; the value checked should have been
        the start of the range
      - when contained regions are detected, previously this was allowed only
        when the old region was uncacheable; this can be symmetric (i.e. the new
        region can also be uncacheable) and even further as per Intel's
        documentation write-trough and write-back for either region is also
        compatible with the respective opposite in the other
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      365bff80
    • A
      [PATCH] i386: fix buggy MTRR address checks · 9b483417
      Andreas Mohr 提交于
      Fix checks that failed to realize that values are 4-kB-unit-sized (note the
      format strings in this same diff context which *do* realize the unit size,
      via appended "000"!).  Also fix an incorrect below-1MB area check (as
      gathered from Jan Beulich's unapplied patch at
      http://www.ussg.iu.edu/hypermail/linux/kernel/0411.1/1378.html ) Update
      mtrr_add_page() docu to make 4-kB-sized calculation more obvious.
      
      Given several further items mentioned in Jan's patch mail, all in all MTRR
      code seems surprisingly buggy, for a surprisingly long period of time (many
      years).  Further work/investigation would be useful.
      
      TBD Note that my patch is pretty much UNTESTED, since I can only verify that it
      TBD successfully boots my machine, but I cannot test against actual buggy
      TBD hardware which would require these (formerly broken) checks.  Long -mm
      TBD simmering would make sense, especially since these now-working checks might
      TBD turn out to have adverse effects on unaffected hardware.
      Signed-off-by: NAndreas Mohr <andi@lisas.de>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Acked-by: NJan Beulich <jbeulich@novell.com>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      9b483417
  17. 26 9月, 2006 1 次提交
  18. 08 7月, 2005 1 次提交
  19. 26 6月, 2005 1 次提交
  20. 01 5月, 2005 1 次提交
  21. 17 4月, 2005 2 次提交