1. 19 6月, 2008 1 次提交
  2. 18 6月, 2008 1 次提交
  3. 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
  4. 04 6月, 2008 2 次提交
    • A
      x86: section mismatch fix · be524fb9
      Andrew Morton 提交于
      Fix this:
      
       WARNING: vmlinux.o(.text+0x114bb): Section mismatch in reference from
       the function nopat() to the function .cpuinit.text:pat_disable()
       The function nopat() references
       the function __cpuinit pat_disable().
       This is often because nopat lacks a __cpuinit
       annotation or the annotation of pat_disable is wrong.
      Reported-by: N"Fabio Comolli" <fabio.comolli@gmail.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      be524fb9
    • V
      x86: fix Xorg crash with xf86MapVidMem error · 282c454c
      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>
      282c454c
  5. 25 5月, 2008 1 次提交
    • A
      arch/x86/mm/pat.c: use boot_cpu_has() · 46dd98a5
      Andrew Morton 提交于
      arch/x86/mm/pat.c: In function 'phys_mem_access_prot_allowed':
      arch/x86/mm/pat.c:526: warning: passing argument 2 of 'constant_test_bit' from incompatible pointer type
      arch/x86/mm/pat.c:526: warning: passing argument 2 of 'variable_test_bit' from incompatible pointer type
      arch/x86/mm/pat.c:527: warning: passing argument 2 of 'constant_test_bit' from incompatible pointer type
      arch/x86/mm/pat.c:527: warning: passing argument 2 of 'variable_test_bit' from incompatible pointer type
      arch/x86/mm/pat.c:528: warning: passing argument 2 of 'constant_test_bit' from incompatible pointer type
      arch/x86/mm/pat.c:528: warning: passing argument 2 of 'variable_test_bit' from incompatible pointer type
      arch/x86/mm/pat.c:529: warning: passing argument 2 of 'constant_test_bit' from incompatible pointer type
      arch/x86/mm/pat.c:529: warning: passing argument 2 of 'variable_test_bit' from incompatible pointer type
      
      Don't open-code test_bit() on a __u32
      
      Cc: Andrea Arcangeli <andrea@qumranet.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      46dd98a5
  6. 18 5月, 2008 1 次提交
  7. 14 5月, 2008 1 次提交
  8. 13 5月, 2008 1 次提交
  9. 08 5月, 2008 1 次提交
    • T
      x86: cleanup PAT cpu validation · 8d4a4300
      Thomas Gleixner 提交于
      Move the scattered checks for PAT support to a single function. Its
      moved to addon_cpuid_features.c as this file is shared between 32 and
      64 bit.
      
      Remove the manipulation of the PAT feature bit and just disable PAT in
      the PAT layer, based on the PAT bit provided by the CPU and the
      current CPU version/model white list.
      
      Change the boot CPU check so it works on Voyager somewhere in the
      future as well :) Also panic, when a secondary has PAT disabled but
      the primary one has alrady switched to PAT. We have no way to undo
      that.
      
      The white list is kept for now to ensure that we can rely on known to
      work CPU types and concentrate on the software induced problems
      instead of fighthing CPU erratas and subtle wreckage caused by not yet
      verified CPUs. Once the PAT code has stabilized enough, we can remove
      the white list and open the can of worms.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8d4a4300
  10. 28 4月, 2008 2 次提交
    • I
      x86: PAT fix · f022bfd5
      Ingo Molnar 提交于
      Adrian Bunk noticed the following Coverity report:
      
      > Commit e7f260a2
      > (x86: PAT use reserve free memtype in mmap of /dev/mem)
      > added the following gem to arch/x86/mm/pat.c:
      >
      > <--  snip  -->
      >
      > ...
      > int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
      >                                 unsigned long size, pgprot_t *vma_prot)
      > {
      >         u64 offset = ((u64) pfn) << PAGE_SHIFT;
      >         unsigned long flags = _PAGE_CACHE_UC_MINUS;
      >         unsigned long ret_flags;
      > ...
      > ...  (nothing that touches ret_flags)
      > ...
      >         if (flags != _PAGE_CACHE_UC_MINUS) {
      >                 retval = reserve_memtype(offset, offset + size, flags, NULL);
      >         } else {
      >                 retval = reserve_memtype(offset, offset + size, -1, &ret_flags);
      >         }
      >
      >         if (retval < 0)
      >                 return 0;
      >
      >         flags = ret_flags;
      >
      >         if (pfn <= max_pfn_mapped &&
      >             ioremap_change_attr((unsigned long)__va(offset), size, flags) < 0) {
      >                 free_memtype(offset, offset + size);
      >                 printk(KERN_INFO
      >                 "%s:%d /dev/mem ioremap_change_attr failed %s for %Lx-%Lx\n",
      >                         current->comm, current->pid,
      >                         cattr_name(flags),
      >                         offset, offset + size);
      >                 return 0;
      >         }
      >
      >         *vma_prot = __pgprot((pgprot_val(*vma_prot) & ~_PAGE_CACHE_MASK) |
      >                              flags);
      >         return 1;
      > }
      >
      > <--  snip  -->
      >
      > If (flags != _PAGE_CACHE_UC_MINUS) we pass garbage from the stack to
      > ioremap_change_attr() and/or __pgprot().
      >
      > Spotted by the Coverity checker.
      
      the fix simplifies the code as we get rid of the 'ret_flags'
      complication.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f022bfd5
    • L
      x86 PAT: tone down debugging messages some more · 86cf02f8
      Linus Torvalds 提交于
      Ingo already fixed one of these at my request (in "x86 PAT: tone down
      debugging messages", commit 1ebcc654),
      but there was another one he missed.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      86cf02f8
  11. 27 4月, 2008 1 次提交
  12. 26 4月, 2008 1 次提交
    • I
      x86 PAT: tone down debugging messages · 1ebcc654
      Ingo Molnar 提交于
      Linus reported these excessive debug printouts:
      
      >       Overlap at 0xe0300000-0xe0400000
      >       Overlap at 0xe0300000-0xe0380000
      >       Overlap at 0xe0300000-0xe0400000
      >       Overlap at 0xe0300000-0xe0400000
      >       Overlap at 0xe0300000-0xe0400000
      >       Overlap at 0xe0300000-0xe0400000
      >       Overlap at 0xe0300000-0xe0400000
      
      turn that into a pr_debug().
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1ebcc654
  13. 25 4月, 2008 3 次提交
  14. 17 4月, 2008 4 次提交