1. 03 3月, 2013 1 次提交
    • Y
      x86, ACPI, mm: Revert movablemem_map support · 20e6926d
      Yinghai Lu 提交于
      Tim found:
      
        WARNING: at arch/x86/kernel/smpboot.c:324 topology_sane.isra.2+0x6f/0x80()
        Hardware name: S2600CP
        sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
        smpboot: Booting Node   1, Processors  #1
        Modules linked in:
        Pid: 0, comm: swapper/1 Not tainted 3.9.0-0-generic #1
        Call Trace:
          set_cpu_sibling_map+0x279/0x449
          start_secondary+0x11d/0x1e5
      
      Don Morris reproduced on a HP z620 workstation, and bisected it to
      commit e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock
      is ready")
      
      It turns out movable_map has some problems, and it breaks several things
      
      1. numa_init is called several times, NOT just for srat. so those
      	nodes_clear(numa_nodes_parsed)
      	memset(&numa_meminfo, 0, sizeof(numa_meminfo))
         can not be just removed.  Need to consider sequence is: numaq, srat, amd, dummy.
         and make fall back path working.
      
      2. simply split acpi_numa_init to early_parse_srat.
         a. that early_parse_srat is NOT called for ia64, so you break ia64.
         b.  for (i = 0; i < MAX_LOCAL_APIC; i++)
      	     set_apicid_to_node(i, NUMA_NO_NODE)
           still left in numa_init. So it will just clear result from early_parse_srat.
           it should be moved before that....
         c.  it breaks ACPI_TABLE_OVERIDE...as the acpi table scan is moved
             early before override from INITRD is settled.
      
      3. that patch TITLE is total misleading, there is NO x86 in the title,
         but it changes critical x86 code. It caused x86 guys did not
         pay attention to find the problem early. Those patches really should
         be routed via tip/x86/mm.
      
      4. after that commit, following range can not use movable ram:
        a. real_mode code.... well..funny, legacy Node0 [0,1M) could be hot-removed?
        b. initrd... it will be freed after booting, so it could be on movable...
        c. crashkernel for kdump...: looks like we can not put kdump kernel above 4G
      	anymore.
        d. init_mem_mapping: can not put page table high anymore.
        e. initmem_init: vmemmap can not be high local node anymore. That is
           not good.
      
      If node is hotplugable, the mem related range like page table and
      vmemmap could be on the that node without problem and should be on that
      node.
      
      We have workaround patch that could fix some problems, but some can not
      be fixed.
      
      So just remove that offending commit and related ones including:
      
       f7210e6c ("mm/memblock.c: use CONFIG_HAVE_MEMBLOCK_NODE_MAP to
          protect movablecore_map in memblock_overlaps_region().")
      
       01a178a9 ("acpi, memory-hotplug: support getting hotplug info from
          SRAT")
      
       27168d38 ("acpi, memory-hotplug: extend movablemem_map ranges to
          the end of node")
      
       e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock is
          ready")
      
       fb06bc8e ("page_alloc: bootmem limit with movablecore_map")
      
       42f47e27 ("page_alloc: make movablemem_map have higher priority")
      
       6981ec31 ("page_alloc: introduce zone_movable_limit[] to keep
          movable limit for nodes")
      
       34b71f1e ("page_alloc: add movable_memmap kernel parameter")
      
       4d59a751 ("x86: get pg_data_t's memory from other node")
      
      Later we should have patches that will make sure kernel put page table
      and vmemmap on local node ram instead of push them down to node0.  Also
      need to find way to put other kernel used ram to local node ram.
      Reported-by: NTim Gardner <tim.gardner@canonical.com>
      Reported-by: NDon Morris <don.morris@hp.com>
      Bisected-by: NDon Morris <don.morris@hp.com>
      Tested-by: NDon Morris <don.morris@hp.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      20e6926d
  2. 02 3月, 2013 2 次提交
    • T
      kgdb/kgdbts: support ppc64 · e78acf67
      Tiejun Chen 提交于
      We can't look up the address of the entry point of the function simply
      via that function symbol for all architectures.
      
      For PPC64 ABI, actually there is a function descriptors structure.
      
      A function descriptor is a three doubleword data structure that contains
      the following values:
      	* The first doubleword contains the address of the entry point of
      		the function.
      	* The second doubleword contains the TOC base address for
      		the function.
      	* The third doubleword contains the environment pointer for
      		languages such as Pascal and PL/1.
      
      So we should call a wapperred dereference_function_descriptor() to get
      the address of the entry point of the function.
      
      Note this is also safe for other architecture after refer to
      "include/asm-generic/sections.h" since:
      
      dereference_function_descriptor(p) always is (p) if without arched definition.
      Signed-off-by: NTiejun Chen <tiejun.chen@windriver.com>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      e78acf67
    • R
      hsi: fix kernel-doc warnings · 8eae508b
      Randy Dunlap 提交于
      Fix kernel-doc warnings in hsi files:
      
        Warning(include/linux/hsi/hsi.h:136): Excess struct/union/enum/typedef member 'e_handler' description in 'hsi_client'
        Warning(include/linux/hsi/hsi.h:136): Excess struct/union/enum/typedef member 'pclaimed' description in 'hsi_client'
        Warning(include/linux/hsi/hsi.h:136): Excess struct/union/enum/typedef member 'nb' description in 'hsi_client'
        Warning(drivers/hsi/hsi.c:434): No description found for parameter 'handler'
        Warning(drivers/hsi/hsi.c:434): Excess function parameter 'cb' description in 'hsi_register_port_event'
      
      Don't document "private:" fields with kernel-doc notation.
      If you want to leave them fully documented, that's OK, but
      then don't mark them as "private:".
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: Carlos Chinea <carlos.chinea@nokia.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-omap@vger.kernel.org
      Acked-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8eae508b
  3. 01 3月, 2013 2 次提交
    • L
      Fix mis-merge of intel_powerclamp.c resulting in compile error · 19cc90f5
      Linus Torvalds 提交于
      The new intel_powerclamp thermal cooling device driver was merged in
      commit 2af78448 (Pull thermal management updates from Zhang Rui)
      without any data conflicts.  But there was a more subtle conflict I
      missed: the driver uses MAX_USER_RT_PRIO, but commit 8bd75c77
      ("sched/rt: Move rt specific bits into new header file") had moved that
      define from <linux/sched.h> to <linux/sched/rt.h>.
      
      Which caused this build failure:
      
        drivers/thermal/intel_powerclamp.c: In function ‘clamp_thread’:
        drivers/thermal/intel_powerclamp.c:360:21: error: ‘MAX_USER_RT_PRIO’ undeclared (first use in this function)
        drivers/thermal/intel_powerclamp.c:360:21: note: each undeclared identifier is reported only once for each function it appears in
      
      And because I don't do a full "make allmodconfig" build after each pull,
      I didn't notice until too late.  So now the fix is here, separately from
      the merge commit.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      19cc90f5
    • G
      clocksource: time-armada-370-xp: add local timer support · ddd3f69f
      Gregory CLEMENT 提交于
      On the SOCs Armada 370 and Armada XP, each CPU comes with two private
      timers. This patch use the timer 0 of each CPU as local timer for the
      clockevent if CONFIG_LOCAL_TIMER is selected. In the other case, use
      only the private Timer 0 of CPU 0.
      Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      ddd3f69f
  4. 28 2月, 2013 35 次提交