1. 26 9月, 2012 33 次提交
  2. 25 9月, 2012 2 次提交
    • M
      phy/micrel: Rename KS80xx to KSZ80xx · 510d573f
      Marek Vasut 提交于
      There is no such part as KS8001, KS8041 or KS8051. There are only
      KSZ8001, KSZ8041 and KSZ8051. Rename these parts as such to match
      the Micrel naming.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: David J. Choi <david.choi@micrel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Cc: Linux ARM kernel <linux-arm-kernel@lists.infradead.org>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      510d573f
    • C
      tile: gxio iorpc numbering change for TRIO interface · e70cf540
      Chris Metcalf 提交于
      An ABI numbering change was made in the hypervisor for Tilera's 4.1
      MDE release (just shipped).  It's incompatible with the previous 4.0
      release ABI numbering, so we track the new numbering going forward.
      We plan to avoid modifying ABI numbering for these interfaces again.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      e70cf540
  3. 24 9月, 2012 1 次提交
    • K
      xen/boot: Disable NUMA for PV guests. · 8d54db79
      Konrad Rzeszutek Wilk 提交于
      The hypervisor is in charge of allocating the proper "NUMA" memory
      and dealing with the CPU scheduler to keep them bound to the proper
      NUMA node. The PV guests (and PVHVM) have no inkling of where they
      run and do not need to know that right now. In the future we will
      need to inject NUMA configuration data (if a guest spans two or more
      NUMA nodes) so that the kernel can make the right choices. But those
      patches are not yet present.
      
      In the meantime, disable the NUMA capability in the PV guest, which
      also fixes a bootup issue. Andre says:
      
      "we see Dom0 crashes due to the kernel detecting the NUMA topology not
      by ACPI, but directly from the northbridge (CONFIG_AMD_NUMA).
      
      This will detect the actual NUMA config of the physical machine, but
      will crash about the mismatch with Dom0's virtual memory. Variation of
      the theme: Dom0 sees what it's not supposed to see.
      
      This happens with the said config option enabled and on a machine where
      this scanning is still enabled (K8 and Fam10h, not Bulldozer class)
      
      We have this dump then:
      NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10
      Scanning NUMA topology in Northbridge 24
      Number of physical nodes 4
      Node 0 MemBase 0000000000000000 Limit 0000000040000000
      Node 1 MemBase 0000000040000000 Limit 0000000138000000
      Node 2 MemBase 0000000138000000 Limit 00000001f8000000
      Node 3 MemBase 00000001f8000000 Limit 0000000238000000
      Initmem setup node 0 0000000000000000-0000000040000000
        NODE_DATA [000000003ffd9000 - 000000003fffffff]
      Initmem setup node 1 0000000040000000-0000000138000000
        NODE_DATA [0000000137fd9000 - 0000000137ffffff]
      Initmem setup node 2 0000000138000000-00000001f8000000
        NODE_DATA [00000001f095e000 - 00000001f0984fff]
      Initmem setup node 3 00000001f8000000-0000000238000000
      Cannot find 159744 bytes in node 3
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
      Pid: 0, comm: swapper Not tainted 3.3.6 #1 AMD Dinar/Dinar
      RIP: e030:[<ffffffff81d220e6>]  [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
      .. snip..
        [<ffffffff81d23024>] sparse_early_usemaps_alloc_node+0x64/0x178
        [<ffffffff81d23348>] sparse_init+0xe4/0x25a
        [<ffffffff81d16840>] paging_init+0x13/0x22
        [<ffffffff81d07fbb>] setup_arch+0x9c6/0xa9b
        [<ffffffff81683954>] ? printk+0x3c/0x3e
        [<ffffffff81d01a38>] start_kernel+0xe5/0x468
        [<ffffffff81d012cf>] x86_64_start_reservations+0xba/0xc1
        [<ffffffff81007153>] ? xen_setup_runstate_info+0x2c/0x36
        [<ffffffff81d050ee>] xen_start_kernel+0x565/0x56c
      "
      
      so we just disable NUMA scanning by setting numa_off=1.
      
      CC: stable@vger.kernel.org
      Reported-and-Tested-by: NAndre Przywara <andre.przywara@amd.com>
      Acked-by: NAndre Przywara <andre.przywara@amd.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      8d54db79
  4. 22 9月, 2012 3 次提交
  5. 21 9月, 2012 1 次提交
    • J
      x86/kbuild: archscripts depends on scripts_basic · 24cc7fb6
      Jeff Mahoney 提交于
      While building the SUSE kernel packages, which build the scripts,
      make clean, and then build everything, we have been running into spurious
      build failures. We tracked them down to a simple dependency issue:
      
      $ make mrproper
        CLEAN   arch/x86/tools
        CLEAN   scripts/basic
      $ cp patches/config/x86_64/desktop .config
      $ make archscripts
        HOSTCC  arch/x86/tools/relocs
      /bin/sh: scripts/basic/fixdep: No such file or directory
      make[3]: *** [arch/x86/tools/relocs] Error 1
      make[2]: *** [archscripts] Error 2
      make[1]: *** [sub-make] Error 2
      make: *** [all] Error 2
      
      This was introduced by commit
      6520fe55 (x86, realmode: 16-bit real-mode code support for relocs),
      which added the archscripts dependency to archprepare.
      
      This patch adds the scripts_basic dependency to the x86 archscripts.
      Signed-off-by: NJeff Mahoney <jeffm@suse.com>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      24cc7fb6