1. 04 10月, 2012 22 次提交
  2. 28 9月, 2012 6 次提交
    • G
      um: Preinclude include/linux/kern_levels.h · 9429ec96
      Geert Uytterhoeven 提交于
      The userspace part of UML uses the asm-offsets.h generator mechanism to
      create definitions for UM_KERN_<LEVEL> that match the in-kernel
      KERN_<LEVEL> constant definitions.
      
      As of commit 04d2c8c8 ("printk: convert
      the format for KERN_<LEVEL> to a 2 byte pattern"), KERN_<LEVEL> is no
      longer expanded to the literal '"<LEVEL>"', but to '"\001" "LEVEL"', i.e.
      it contains two parts.
      
      However, the combo of DEFINE_STR() in
      arch/x86/um/shared/sysdep/kernel-offsets.h and sed-y in Kbuild doesn't
      support string literals consisting of multiple parts. Hence for all
      UM_KERN_<LEVEL> definitions, only the SOH character is retained in the actual
      definition, while the remainder ends up in the comment. E.g. in
      include/generated/asm-offsets.h we get
      
          #define UM_KERN_INFO "\001" /* "6" KERN_INFO */
      
      instead of
      
          #define UM_KERN_INFO "\001" "6" /* KERN_INFO */
      
      This causes spurious '^A' output in some kernel messages:
      
          Calibrating delay loop... 4640.76 BogoMIPS (lpj=23203840)
          pid_max: default: 32768 minimum: 301
          Mount-cache hash table entries: 256
          ^AChecking that host ptys support output SIGIO...Yes
          ^AChecking that host ptys support SIGIO on close...No, enabling workaround
          ^AUsing 2.6 host AIO
          NET: Registered protocol family 16
          bio: create slab <bio-0> at 0
          Switching to clocksource itimer
      
      To fix this:
        - Move the mapping from UM_KERN_<LEVEL> to KERN_<LEVEL> from
          arch/um/include/shared/common-offsets.h to
          arch/um/include/shared/user.h, which is preincluded for all userspace
          parts,
        - Preinclude include/linux/kern_levels.h for all userspace parts, to
          obtain the in-kernel KERN_<LEVEL> constant definitions. This doesn't
          violate the kernel/userspace separation, as include/linux/kern_levels.h
          is self-contained and doesn't expose any other kernel internals.
        - Remove the now unused STR() and DEFINE_STR() macros.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      9429ec96
    • R
      um: Fix IPC on um · bbb35efc
      Richard Weinberger 提交于
      commit c1d7e01d (ipc: use Kconfig options for __ARCH_WANT_[COMPAT_]IPC_PARSE_VERSION)
      forgot UML and broke IPC on it.
      Also UML has to select ARCH_WANT_IPC_PARSE_VERSION usin Kconfig.
      
      Reported-and-tested-by: <Toralf Förster toralf.foerster@gmx.de>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      bbb35efc
    • A
      um: kill thread->forking · d2ce4e92
      Al Viro 提交于
      we only use that to tell copy_thread() done by syscall from that
      done by kernel_thread().  However, it's easier to do simply by
      checking PF_KTHREAD in thread flags.
      
      Merge sys_clone() guts for 32bit and 64bit, while we are at it...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d2ce4e92
    • A
      um: let signal_delivered() do SIGTRAP on singlestepping into handler · f9a38eac
      Al Viro 提交于
      ... rather than duplicating that in sigframe setup code (and doing that
      inconsistently, at that)
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      f9a38eac
    • A
    • A
      um: take cleaning singlestep to start_thread() · 42459792
      Al Viro 提交于
      ... assuming it's needed to be done at all
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      42459792
  3. 27 9月, 2012 1 次提交
  4. 25 9月, 2012 3 次提交
    • 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
    • M
      c6x: use asm-generic/barrier.h · b02d6175
      Mark Salter 提交于
      A recent patch in the linux-next tree caused a build failure on
      C6X because C6X didn't define a read_barrier_depends() macro. C6X
      does not support SMP and the architecture doesn't provide any
      special memory ordering instructions, so it makes sense to just
      use the generic barrier.h rather than patching the existing c6x
      specific header.
      Signed-off-by: NMark Salter <msalter@redhat.com>
      b02d6175
  5. 24 9月, 2012 2 次提交
    • 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
    • S
      ARM: dma-mapping: Fix potential memory leak in atomic_pool_init() · ec10665c
      Sachin Kamat 提交于
      When either of __alloc_from_contiguous or __alloc_remap_buffer fails
      to provide a valid pointer, allocated memory is freed up and an error
      is returned. 'pages' was however not freed before returning error.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      ec10665c
  6. 22 9月, 2012 3 次提交
  7. 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
  8. 20 9月, 2012 2 次提交
    • M
      ARM: 7535/1: Reprogram smp_twd based on new common clk framework notifiers · 2b25d9f6
      Mike Turquette 提交于
      Running cpufreq driver on imx6q, the following warning is seen.
      
      $ BUG: sleeping function called from invalid context at kernel/mutex.c:269
      
      <snip>
      
      stack backtrace:
      Backtrace:
      [<80011d64>] (dump_backtrace+0x0/0x10c) from [<803fc164>] (dump_stack+0x18/0x1c)
       r6:bf8142e0 r5:bf814000 r4:806ac794 r3:bf814000
      [<803fc14c>] (dump_stack+0x0/0x1c) from [<803fd444>] (print_usage_bug+0x250/0x2b
      8)
      [<803fd1f4>] (print_usage_bug+0x0/0x2b8) from [<80060f90>] (mark_lock+0x56c/0x67
      0)
      [<80060a24>] (mark_lock+0x0/0x670) from [<80061a20>] (__lock_acquire+0x98c/0x19b
      4)
      [<80061094>] (__lock_acquire+0x0/0x19b4) from [<80062f14>] (lock_acquire+0x68/0x
      7c)
      [<80062eac>] (lock_acquire+0x0/0x7c) from [<80400f28>] (mutex_lock_nested+0x78/0
      x344)
       r7:00000000 r6:bf872000 r5:805cc858 r4:805c2a04
      [<80400eb0>] (mutex_lock_nested+0x0/0x344) from [<803089ac>] (clk_get_rate+0x1c/
      0x58)
      [<80308990>] (clk_get_rate+0x0/0x58) from [<80013c48>] (twd_update_frequency+0x1
      8/0x50)
       r5:bf253d04 r4:805cadf4
      [<80013c30>] (twd_update_frequency+0x0/0x50) from [<80068e20>] (generic_smp_call
      _function_single_interrupt+0xd4/0x13c)
       r4:bf873ee0 r3:80013c30
      [<80068d4c>] (generic_smp_call_function_single_interrupt+0x0/0x13c) from [<80013
      34c>] (handle_IPI+0xc0/0x194)
       r8:00000001 r7:00000000 r6:80574e48 r5:bf872000 r4:80593958
      [<8001328c>] (handle_IPI+0x0/0x194) from [<800084e8>] (gic_handle_irq+0x58/0x60)
       r8:00000000 r7:bf873f8c r6:bf873f58 r5:80593070 r4:f4000100
      r3:00000005
      [<80008490>] (gic_handle_irq+0x0/0x60) from [<8000e124>] (__irq_svc+0x44/0x60)
      Exception stack(0xbf873f58 to 0xbf873fa0)
      3f40:                                                       00000001 00000001
      3f60: 00000000 bf814000 bf872000 805cab48 80405aa4 80597648 00000000 412fc09a
      3f80: bf872000 bf873fac bf873f70 bf873fa0 80063844 8000f1f8 20000013 ffffffff
       r6:ffffffff r5:20000013 r4:8000f1f8 r3:bf814000
      [<8000f1b8>] (default_idle+0x0/0x4c) from [<8000f428>] (cpu_idle+0x98/0x114)
      [<8000f390>] (cpu_idle+0x0/0x114) from [<803f9834>] (secondary_start_kernel+0x11
      c/0x140)
      [<803f9718>] (secondary_start_kernel+0x0/0x140) from [<103f9234>] (0x103f9234)
       r6:10c03c7d r5:0000001f r4:4f86806a r3:803f921c
      
      It looks that the warning is caused by that twd_update_frequency() gets
      called from an atomic context while it calls clk_get_rate() where a
      mutex gets held.
      
      To fix the warning, let's convert common clk users over to clk notifiers
      in place of CPUfreq notifiers.  This works out nicely for Cortex-A9
      MPcore designs that scale all CPUs at the same frequency.
      
      Platforms that have not been converted to the common clk framework and
      support CPUfreq will rely on the old mechanism.  Once these platforms
      are converted over fully then we can remove the CPUfreq-specific bits
      for good.
      Signed-off-by: NMike Turquette <mturquette@linaro.org>
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2b25d9f6
    • K
      xen/boot: Disable BIOS SMP MP table search. · bd49940a
      Konrad Rzeszutek Wilk 提交于
      As the initial domain we are able to search/map certain regions
      of memory to harvest configuration data. For all low-level we
      use ACPI tables - for interrupts we use exclusively ACPI _PRT
      (so DSDT) and MADT for INT_SRC_OVR.
      
      The SMP MP table is not used at all. As a matter of fact we do
      not even support machines that only have SMP MP but no ACPI tables.
      
      Lets follow how Moorestown does it and just disable searching
      for BIOS SMP tables.
      
      This also fixes an issue on HP Proliant BL680c G5 and DL380 G6:
      
      9f->100 for 1:1 PTE
      Freeing 9f-100 pfn range: 97 pages freed
      1-1 mapping on 9f->100
      .. snip..
      e820: BIOS-provided physical RAM map:
      Xen: [mem 0x0000000000000000-0x000000000009efff] usable
      Xen: [mem 0x000000000009f400-0x00000000000fffff] reserved
      Xen: [mem 0x0000000000100000-0x00000000cfd1dfff] usable
      .. snip..
      Scan for SMP in [mem 0x00000000-0x000003ff]
      Scan for SMP in [mem 0x0009fc00-0x0009ffff]
      Scan for SMP in [mem 0x000f0000-0x000fffff]
      found SMP MP-table at [mem 0x000f4fa0-0x000f4faf] mapped at [ffff8800000f4fa0]
      (XEN) mm.c:908:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 0000000000100461 for l1e_owner=0, pg_owner=0
      (XEN) mm.c:4995:d0 ptwr_emulate: could not get_page_from_l1e()
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff81ac07e2>] xen_set_pte_init+0x66/0x71
      . snip..
      Pid: 0, comm: swapper Not tainted 3.6.0-rc6upstream-00188-gb6fb969-dirty #2 HP ProLiant BL680c G5
      .. snip..
      Call Trace:
       [<ffffffff81ad31c6>] __early_ioremap+0x18a/0x248
       [<ffffffff81624731>] ? printk+0x48/0x4a
       [<ffffffff81ad32ac>] early_ioremap+0x13/0x15
       [<ffffffff81acc140>] get_mpc_size+0x2f/0x67
       [<ffffffff81acc284>] smp_scan_config+0x10c/0x136
       [<ffffffff81acc2e4>] default_find_smp_config+0x36/0x5a
       [<ffffffff81ac3085>] setup_arch+0x5b3/0xb5b
       [<ffffffff81624731>] ? printk+0x48/0x4a
       [<ffffffff81abca7f>] start_kernel+0x90/0x390
       [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
       [<ffffffff81abfa83>] xen_start_kernel+0x65f/0x661
      (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
      
      which is that ioremap would end up mapping 0xff using _PAGE_IOMAP
      (which is what early_ioremap sticks as a flag) - which meant
      we would get MFN 0xFF (pte ff461, which is OK), and then it would
      also map 0x100 (b/c ioremap tries to get page aligned request, and
      it was trying to map 0xf4fa0 + PAGE_SIZE - so it mapped the next page)
      as _PAGE_IOMAP. Since 0x100 is actually a RAM page, and the _PAGE_IOMAP
      bypasses the P2M lookup we would happily set the PTE to 1000461.
      Xen would deny the request since we do not have access to the
      Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
      0x80140.
      
      CC: stable@vger.kernel.org
      Fixes-Oracle-Bugzilla: https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665Acked-by: NJan Beulich <jbeulich@suse.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      bd49940a