1. 24 1月, 2009 1 次提交
    • H
      x86: handle PAT more like other CPU features · 75a04811
      H. Peter Anvin 提交于
      Impact: Cleanup
      
      When PAT was originally introduced, it was handled specially for a few
      reasons:
      
      - PAT bugs are hard to track down, so we wanted to maintain a
        whitelist of CPUs.
      - The i386 and x86-64 CPUID code was not yet unified.
      
      Both of these are now obsolete, so handle PAT like any other features,
      including ordinary feature blacklisting due to known bugs.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      75a04811
  2. 16 1月, 2009 1 次提交
  3. 14 1月, 2009 3 次提交
    • V
      x86 PAT: remove CPA WARN_ON for zero pte · 58dab916
      venkatesh.pallipadi@intel.com 提交于
      Impact: reduce scope of debug check - avoid warnings
      
      The logic to find whether identity map exists or not using
      high_memory or max_low_pfn_mapped/max_pfn_mapped are not complete
      as the memory withing the range may not be mapped if there is a
      unusable hole in e820.
      
      Specifically, on my test system I started seeing these warnings with
      tools like hwinfo, acpidump trying to map ACPI region.
      
      [   27.400018] ------------[ cut here ]------------
      [   27.400344] WARNING: at /home/venkip/src/linus/linux-2.6/arch/x86/mm/pageattr.c:560 __change_page_attr_set_clr+0xf3/0x8b8()
      [   27.400821] Hardware name: X7DB8
      [   27.401070] CPA: called for zero pte. vaddr = ffff8800cff6a000 cpa->vaddr = ffff8800cff6a000
      [   27.401569] Modules linked in:
      [   27.401882] Pid: 4913, comm: dmidecode Not tainted 2.6.28-05716-gfe0bdec6 #586
      [   27.402141] Call Trace:
      [   27.402488]  [<ffffffff80237c21>] warn_slowpath+0xd3/0x10f
      [   27.402749]  [<ffffffff80274ade>] ? find_get_page+0xb3/0xc9
      [   27.403028]  [<ffffffff80274a2b>] ? find_get_page+0x0/0xc9
      [   27.403333]  [<ffffffff80226425>] __change_page_attr_set_clr+0xf3/0x8b8
      [   27.403628]  [<ffffffff8028ec99>] ? __purge_vmap_area_lazy+0x192/0x1a1
      [   27.403883]  [<ffffffff8028eb52>] ? __purge_vmap_area_lazy+0x4b/0x1a1
      [   27.404172]  [<ffffffff80290268>] ? vm_unmap_aliases+0x1ab/0x1bb
      [   27.404512]  [<ffffffff80290105>] ? vm_unmap_aliases+0x48/0x1bb
      [   27.404766]  [<ffffffff80226d28>] change_page_attr_set_clr+0x13e/0x2e6
      [   27.405026]  [<ffffffff80698fa7>] ? _spin_unlock+0x26/0x2a
      [   27.405292]  [<ffffffff80227e6a>] ? reserve_memtype+0x19b/0x4e3
      [   27.405590]  [<ffffffff80226ffd>] _set_memory_wb+0x22/0x24
      [   27.405844]  [<ffffffff80225d28>] ioremap_change_attr+0x26/0x28
      [   27.406097]  [<ffffffff80228355>] reserve_pfn_range+0x1a3/0x235
      [   27.406427]  [<ffffffff80228430>] track_pfn_vma_new+0x49/0xb3
      [   27.406686]  [<ffffffff80286c46>] remap_pfn_range+0x94/0x32c
      [   27.406940]  [<ffffffff8022878d>] ? phys_mem_access_prot_allowed+0xb5/0x1a8
      [   27.407209]  [<ffffffff803e9bf4>] mmap_mem+0x75/0x9d
      [   27.407523]  [<ffffffff8028b3b4>] mmap_region+0x2cf/0x53e
      [   27.407776]  [<ffffffff8028b8cc>] do_mmap_pgoff+0x2a9/0x30d
      [   27.408034]  [<ffffffff8020f4a4>] sys_mmap+0x92/0xce
      [   27.408339]  [<ffffffff8020b65b>] system_call_fastpath+0x16/0x1b
      [   27.408614] ---[ end trace 4b16ad70c09a602d ]---
      [   27.408871] dmidecode:4913 reserve_pfn_range ioremap_change_attr failed write-back for cff6a000-cff6b000
      
      This is wih track_pfn_vma_new trying to keep identity map in sync.
      The address cff6a000 is the ACPI region according to e820.
      
      [    0.000000] BIOS-provided physical RAM map:
      [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009c000 (usable)
      [    0.000000]  BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved)
      [    0.000000]  BIOS-e820: 00000000000cc000 - 00000000000d0000 (reserved)
      [    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
      [    0.000000]  BIOS-e820: 0000000000100000 - 00000000cff60000 (usable)
      [    0.000000]  BIOS-e820: 00000000cff60000 - 00000000cff69000 (ACPI data)
      [    0.000000]  BIOS-e820: 00000000cff69000 - 00000000cff80000 (ACPI NVS)
      [    0.000000]  BIOS-e820: 00000000cff80000 - 00000000d0000000 (reserved)
      [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
      [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
      [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
      [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
      [    0.000000]  BIOS-e820: 0000000100000000 - 0000000230000000 (usable)
      
      And is not mapped as per init_memory_mapping.
      
      [    0.000000] init_memory_mapping: 0000000000000000-00000000cff60000
      [    0.000000] init_memory_mapping: 0000000100000000-0000000230000000
      
      We can add logic to check for this. But, there can also be other holes in
      identity map when we have 1GB of aligned reserved space in e820.
      
      This patch handles it by removing the WARN_ON and returning a specific
      error value (EFAULT) to indicate that the address does not have any
      identity mapping.
      
      The code that tries to keep identity map in sync can ignore
      this error, with other callers of cpa still getting error here.
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      58dab916
    • V
      x86 PAT: return compatible mapping to remap_pfn_range callers · cdecff68
      venkatesh.pallipadi@intel.com 提交于
      Impact: avoid warning message, potentially solve 3D performance regression
      
      Change x86 PAT code to return compatible memtype if the exact memtype that
      was requested in remap_pfn_rage and friends is not available due to some
      conflict.
      
      This is done by returning the compatible type in pgprot parameter of
      track_pfn_vma_new(), and the caller uses that memtype for page table.
      
      Note that track_pfn_vma_copy() which is basically called during fork gets the
      prot from existing page table and should not have any conflict. Hence we use
      strict memtype check there and do not allow compatible memtypes.
      
      This patch fixes the bug reported here:
      
        http://marc.info/?l=linux-kernel&m=123108883716357&w=2
      
      Specifically the error message:
      
        X:5010 map pfn expected mapping type write-back for d0000000-d0101000,
        got write-combining
      
      Should go away.
      Reported-and-bisected-by: NKevin Winchester <kjwinchester@gmail.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cdecff68
    • V
      x86 PAT: change track_pfn_vma_new to take pgprot_t pointer param · e4b866ed
      venkatesh.pallipadi@intel.com 提交于
      Impact: cleanup
      
      Change the protection parameter for track_pfn_vma_new() into a pgprot_t pointer.
      Subsequent patch changes the x86 PAT handling to return a compatible
      memtype in pgprot_t, if what was requested cannot be allowed due to conflicts.
      No fuctionality change in this patch.
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e4b866ed
  4. 24 12月, 2008 1 次提交
    • H
      x86: PAT: fix address types in track_pfn_vma_new() · c1c15b65
      H. Peter Anvin 提交于
      Impact: cleanup, fix warning
      
      This warning:
      
       arch/x86/mm/pat.c: In function track_pfn_vma_copy:
       arch/x86/mm/pat.c:701: warning: passing argument 5 of follow_phys from incompatible pointer type
      
      Triggers because physical addresses are resource_size_t, not u64.
      
      This really matters when calling an interface like follow_phys() which
      takes a pointer to a physical address -- although on x86, being
      littleendian, it would generally work anyway as long as the memory region
      wasn't completely uninitialized.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c1c15b65
  5. 20 12月, 2008 1 次提交
  6. 19 12月, 2008 2 次提交
  7. 31 10月, 2008 1 次提交
  8. 11 10月, 2008 2 次提交
  9. 21 8月, 2008 1 次提交
  10. 20 8月, 2008 1 次提交
  11. 12 8月, 2008 1 次提交
  12. 20 7月, 2008 1 次提交
    • I
      Subject: devmem, x86: fix rename of CONFIG_NONPROMISC_DEVMEM · d092633b
      Ingo Molnar 提交于
      From: Arjan van de Ven <arjan@infradead.org>
      Date: Sat, 19 Jul 2008 15:47:17 -0700
      
      CONFIG_NONPROMISC_DEVMEM was a rather confusing name - but renaming it
      to CONFIG_PROMISC_DEVMEM causes problems on architectures that do not
      support this feature; this patch renames it to CONFIG_STRICT_DEVMEM,
      so that architectures can opt-in into it.
      
      ( the polarity of the option is still the same as it was originally; it
        needs to be for now to not break architectures that don't have the
        infastructure yet to support this feature)
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Cc: "V.Radhakrishnan" <rk@atr-labs.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ---
      d092633b
  13. 19 7月, 2008 1 次提交
  14. 18 7月, 2008 1 次提交
    • I
      x86: rename CONFIG_NONPROMISC_DEVMEM to CONFIG_PROMISC_DEVMEM · 64d206d8
      Ingo Molnar 提交于
      Linus observed:
      
      > The real bug is that we shouldn't have "double negatives", and
      > certainly not negative config options. Making that "promiscuous
      > /dev/mem" option a negated thing as a config option was bad.
      
      right ... lets rename this option. There should never be a negation
      in config options.
      
      [ that reminds me of CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER, but that
        is for another commit ;-) ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      64d206d8
  15. 13 7月, 2008 1 次提交
  16. 11 7月, 2008 1 次提交
  17. 24 6月, 2008 7 次提交
  18. 19 6月, 2008 1 次提交
  19. 18 6月, 2008 1 次提交
  20. 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
  21. 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
  22. 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
  23. 18 5月, 2008 1 次提交
  24. 14 5月, 2008 1 次提交
  25. 13 5月, 2008 1 次提交
  26. 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