1. 09 2月, 2009 1 次提交
  2. 05 2月, 2009 5 次提交
  3. 04 2月, 2009 2 次提交
  4. 03 2月, 2009 1 次提交
  5. 01 2月, 2009 3 次提交
  6. 31 1月, 2009 9 次提交
  7. 30 1月, 2009 2 次提交
  8. 29 1月, 2009 1 次提交
  9. 28 1月, 2009 1 次提交
  10. 27 1月, 2009 2 次提交
  11. 26 1月, 2009 3 次提交
    • R
      x86: fix section mismatch warning · 659d2618
      Rakib Mullick 提交于
      Here function vmi_activate calls a init function activate_vmi , which
      causes the following section mismatch warnings:
      
        LD      arch/x86/kernel/built-in.o
      WARNING: arch/x86/kernel/built-in.o(.text+0x13ba9): Section mismatch
      in reference from the function vmi_activate() to the function
      .init.text:vmi_time_init()
      The function vmi_activate() references
      the function __init vmi_time_init().
      This is often because vmi_activate lacks a __init
      annotation or the annotation of vmi_time_init is wrong.
      
      WARNING: arch/x86/kernel/built-in.o(.text+0x13bd1): Section mismatch
      in reference from the function vmi_activate() to the function
      .devinit.text:vmi_time_bsp_init()
      The function vmi_activate() references
      the function __devinit vmi_time_bsp_init().
      This is often because vmi_activate lacks a __devinit
      annotation or the annotation of vmi_time_bsp_init is wrong.
      
      WARNING: arch/x86/kernel/built-in.o(.text+0x13bdb): Section mismatch
      in reference from the function vmi_activate() to the function
      .devinit.text:vmi_time_ap_init()
      The function vmi_activate() references
      the function __devinit vmi_time_ap_init().
      This is often because vmi_activate lacks a __devinit
      annotation or the annotation of vmi_time_ap_init is wrong.
      
      Fix it by marking vmi_activate() as __init too.
      Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      659d2618
    • I
      x86: unmask CPUID levels on Intel CPUs, fix · 99fb4d34
      Ingo Molnar 提交于
      Impact: fix boot hang on pre-model-15 Intel CPUs
      
      rdmsrl_safe() does not work in very early bootup code yet, because we
      dont have the pagefault handler installed yet so exception section
      does not get parsed. rdmsr_safe() will just crash and hang the bootup.
      
      So limit the MSR_IA32_MISC_ENABLE MSR read to those CPU types that
      support it.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      99fb4d34
    • E
      x86: work around PAGE_KERNEL_WC not getting WC in iomap_atomic_prot_pfn. · ef5fa0ab
      Eric Anholt 提交于
      In the absence of PAT, PAGE_KERNEL_WC ends up mapping to a memory type that
      gets UC behavior even in the presence of a WC MTRR covering the area in
      question.  By swapping to PAGE_KERNEL_UC_MINUS, we can get the actual
      behavior the caller wanted (WC if you can manage it, UC otherwise).
      
      This recovers the 40% performance improvement of using WC in the DRM
      to upload vertex data.
      Signed-off-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      ef5fa0ab
  12. 25 1月, 2009 1 次提交
    • I
      x86: use standard PIT frequency · e1b4d114
      Ingo Molnar 提交于
      the RDC and ELAN platforms use slighly different PIT clocks, resulting in
      a timex.h hack that changes PIT_TICK_RATE during build time. But if a
      tester enables any of these platform support .config options, the PIT
      will be miscalibrated on standard PC platforms.
      
      So use one frequency - in a subsequent patch we'll add a quirk to allow
      x86 platforms to define different PIT frequencies.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e1b4d114
  13. 24 1月, 2009 1 次提交
    • P
      x86, mm: fix pte_free() · 42ef73fe
      Peter Zijlstra 提交于
      On -rt we were seeing spurious bad page states like:
      
      Bad page state in process 'firefox'
      page:c1bc2380 flags:0x40000000 mapping:c1bc2390 mapcount:0 count:0
      Trying to fix it up, but a reboot is needed
      Backtrace:
      Pid: 503, comm: firefox Not tainted 2.6.26.8-rt13 #3
      [<c043d0f3>] ? printk+0x14/0x19
      [<c0272d4e>] bad_page+0x4e/0x79
      [<c0273831>] free_hot_cold_page+0x5b/0x1d3
      [<c02739f6>] free_hot_page+0xf/0x11
      [<c0273a18>] __free_pages+0x20/0x2b
      [<c027d170>] __pte_alloc+0x87/0x91
      [<c027d25e>] handle_mm_fault+0xe4/0x733
      [<c043f680>] ? rt_mutex_down_read_trylock+0x57/0x63
      [<c043f680>] ? rt_mutex_down_read_trylock+0x57/0x63
      [<c0218875>] do_page_fault+0x36f/0x88a
      
      This is the case where a concurrent fault already installed the PTE and
      we get to free the newly allocated one.
      
      This is due to pgtable_page_ctor() doing the spin_lock_init(&page->ptl)
      which is overlaid with the {private, mapping} struct.
      
      union {
          struct {
              unsigned long private;
              struct address_space *mapping;
          };
          spinlock_t ptl;
          struct kmem_cache *slab;
          struct page *first_page;
      };
      
      Normally the spinlock is small enough to not stomp on page->mapping, but
      PREEMPT_RT=y has huge 'spin'locks.
      
      But lockdep kernels should also be able to trigger this splat, as the
      lock tracking code grows the spinlock to cover page->mapping.
      
      The obvious fix is calling pgtable_page_dtor() like the regular pte free
      path __pte_free_tlb() does.
      
      It seems all architectures except x86 and nm10300 already do this, and
      nm10300 doesn't seem to use pgtable_page_ctor(), which suggests it
      doesn't do SMP or simply doesnt do MMU at all or something.
      Signed-off-by: NPeter Zijlstra <a.p.zijlsta@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      42ef73fe
  14. 22 1月, 2009 5 次提交
  15. 21 1月, 2009 3 次提交
    • T
      x86: mtrr fix debug boot parameter · 731f1872
      Thomas Renninger 提交于
      while looking at:
      
        http://bugzilla.kernel.org/show_bug.cgi?id=11541
      
      I realized that the mtrr.show param cannot work, because
      the code is processed much too early.
      
      This patch:
       - Declares mtrr.show as early_param
       - Stays consistent with the previous param (which I doubt
         that it ever worked), so mtrr.show=1 would still work
       - Declares mtrr_show as initdata
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Acked-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      731f1872
    • S
      x86: fix page attribute corruption with cpa() · a1e46212
      Suresh Siddha 提交于
      Impact: fix sporadic slowdowns and warning messages
      
      This patch fixes a performance issue reported by Linus on his
      Nehalem system. While Linus reverted the PAT patch (commit
      58dab916) which exposed the issue,
      existing cpa() code can potentially still cause wrong(page attribute
      corruption) behavior.
      
      This patch also fixes the "WARNING: at arch/x86/mm/pageattr.c:560" that
      various people reported.
      
      In 64bit kernel, kernel identity mapping might have holes depending
      on the available memory and how e820 reports the address range
      covering the RAM, ACPI, PCI reserved regions. If there is a 2MB/1GB hole
      in the address range that is not listed by e820 entries, kernel identity
      mapping will have a corresponding hole in its 1-1 identity mapping.
      
      If cpa() happens on the kernel identity mapping which falls into these holes,
      existing code fails like this:
      
      	__change_page_attr_set_clr()
      		__change_page_attr()
      			returns 0 because of if (!kpte). But doesn't
      			set cpa->numpages and cpa->pfn.
      		cpa_process_alias()
      			uses uninitialized cpa->pfn (random value)
      			which can potentially lead to changing the page
      			attribute of kernel text/data, kernel identity
      			mapping of RAM pages etc. oops!
      
      This bug was easily exposed by another PAT patch which was doing
      cpa() more often on kernel identity mapping holes (physical range between
      max_low_pfn_mapped and 4GB), where in here it was setting the
      cache disable attribute(PCD) for kernel identity mappings aswell.
      
      Fix cpa() to handle the kernel identity mapping holes. Retain
      the WARN() for cpa() calls to other not present address ranges
      (kernel-text/data, ioremap() addresses)
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a1e46212
    • I
      Revert "x86: signal: change type of paramter for sys_rt_sigreturn()" · 552b8aa4
      Ingo Molnar 提交于
      This reverts commit 4217458d.
      
      Justin Madru bisected this commit, it was causing weird Firefox
      crashes.
      
      The reason is that GCC mis-optimizes (re-uses) the on-stack parameters of
      the calling frame, which corrupts the syscall return pt_regs state and
      thus corrupts user-space register state.
      
      So we go back to the slightly less clean but more optimization-safe
      method of getting to pt_regs. Also add a comment to explain this.
      
      Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=12505Reported-and-bisected-by: NJustin Madru <jdm64@gawab.com>
      Tested-by: NJustin Madru <jdm64@gawab.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      552b8aa4
新手
引导
客服 返回
顶部