1. 08 7月, 2008 16 次提交
  2. 03 7月, 2008 2 次提交
  3. 01 7月, 2008 1 次提交
  4. 26 6月, 2008 1 次提交
    • D
      x86: section/warning fixes · 0b1faeef
      Daniel J Blueman 提交于
      WARNING: arch/x86/mm/built-in.o(.text+0x3a1): Section mismatch in
      reference from the function set_pte_phys() to the function
      .init.text:spp_getpage()
      The function set_pte_phys() references
      the function __init spp_getpage().
      This is often because set_pte_phys lacks a __init
      annotation or the annotation of spp_getpage is wrong.
      
      arch/x86/mm/init_64.c: In function 'early_memtest':
      arch/x86/mm/init_64.c:520: warning: passing argument 2 of
      'find_e820_area_size' from incompatible pointer type
      Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Cc: "Linus Torvalds" <torvalds@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0b1faeef
  5. 24 6月, 2008 7 次提交
  6. 20 6月, 2008 4 次提交
  7. 19 6月, 2008 1 次提交
  8. 18 6月, 2008 1 次提交
  9. 13 6月, 2008 3 次提交
  10. 12 6月, 2008 4 次提交
    • A
      x86: rename pat_wc_enabled to pat_enabled · 499f8f84
      Andreas Herrmann 提交于
      BTW, what does pat_wc_enabled stand for? Does it mean
      "write-combining"?
      
      Currently it is used to globally switch on or off PAT support.
      Thus I renamed it to pat_enabled.
      I think this increases readability (and hope that I didn't miss
      something).
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      499f8f84
    • A
      x86: PAT: fixed checkpatch errors (and whitespaces) · cd7a4e93
      Andreas Herrmann 提交于
      x86: PAT: fixed checkpatch errors (and whitespaces)
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cd7a4e93
    • A
      x86: PAT: fix ambiguous paranoia check in pat_init() · 97cfab6a
      Andreas Herrmann 提交于
      Starting with commit 8d4a4300 (x86:
      cleanup PAT cpu validation) the PAT CPU feature flag is not cleared
      anymore. Now the error message
      
        "PAT enabled, but CPU feature cleared"
      
      in pat_init() is misleading.
      
      Furthermore the current code does not check for existence of the PAT
      CPU feature flag if a CPU is whitelisted in validate_pat_support.
      
      This patch clears pat_wc_enabled if boot CPU has no PAT feature flag
      and adapts the paranoia check.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      97cfab6a
    • V
      x86: fix Xorg crash with xf86MapVidMem error · c26421d0
      Venki Pallipadi 提交于
      Clarify the usage of mtrr_lookup() in PAT code, and to make PAT code
      resilient to mtrr lookup problems.
      
      Specifically, pat_x_mtrr_type() is restructured to highlight, under what
      conditions we look for mtrr hint. pat_x_mtrr_type() uses a default type
      when there are any errors in mtrr lookup (still maintaining the pat
      consistency). And, reserve_memtype() highlights its usage ot mtrr_lookup
      for request type of '-1' and also defaults in a sane way on any mtrr
      lookup failure.
      
      pat.c looks at mtrr type of a range to get a hint on what mapping type
      to request when user/API: (1) hasn't specified any type (/dev/mem
      mapping) and we do not want to take performance hit by always mapping
      UC_MINUS. This will be the case for /dev/mem mappings used to map BIOS
      area or ACPI region which are WB'able. In this case, as long as MTRR is
      not WB, PAT will request UC_MINUS for such mappings.
      
      (2) user/API requests WB mapping while in reality MTRR may have UC or
      WC. In this case, PAT can map as WB (without checking MTRR) and still
      effective type will be UC or WC. But, a subsequent request to map same
      region as UC or WC may fail, as the region will get trackked as WB in
      PAT list. Looking at MTRR hint helps us to track based on effective type
      rather than what user requested. Again, here mtrr_lookup is only used as
      hint and we fallback to WB mapping (as requested by user) as default.
      
      In both cases, after using the mtrr hint, we still go through the
      memtype list to make sure there are no inconsistencies among multiple
      users.
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Tested-by: NRufus &amp; Azrael <rufus-azrael@numericable.fr>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c26421d0