1. 19 10月, 2012 3 次提交
  2. 18 10月, 2012 6 次提交
    • J
      MIPS: CMP: Fix physical core number calculation logic · 0cc40dac
      jerin jacob 提交于
      The CPUNum Field in EBase register is 10bit wide, so after 1 bit right
      shift, the mask value should be 0x1ff.
      Signed-off-by: Njerin jacob <jerinjacobk@gmail.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/4420/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      0cc40dac
    • D
      cpuidle/powerpc: Fix snooze state problem in the cpuidle design on pseries. · 83dac594
      Deepthi Dharwar 提交于
      Earlier without cpuidle framework on pseries, the native arch
      idle routine comprised of both snooze and nap
      states.  smt_snooze_delay variable was used to delay
      the idle process entry to deeper idle state like  nap.
      With the coming of cpuidle, this arch specific idle was replaced
      by two different idle routines, one for supporting snooze and other
      for nap. This enabled addition of more
      low level idle states on pseries in the future.
      
      On adopting the generic cpuidle framework for POWER systems,
      the decision of which idle state to choose from,  given a predicted
      idle time is taken by the menu governor based on
      target_residency and  exit_latency of the idle states.
      target_residency is the minimum time to be resident in that idle state.
      Exit_latency is time taken to exit out of idle state.
      Deeper the idle state, both the target residency and exit latency
      would be higher.
      
      In the current design, smt_snooze_delay is used as target_residency
      for the  snooze state which is incorrect, as it is not the
      minimum but the maximum duration to be in snooze state.
      This would  result in the governor in taking bad decision,
      as presently target_residency of nap < target_residency of snooze
      inspite of nap being deeper idle state.
      
      This patch aims to fix this problem by replacing the smt_snooze_delay loop
      in snooze state, with the need_resched()  as the governor is aware of
      entry and exit of various idle transitions based on which
      next idle time prediction.
      
      The governor is intelligent enough to determine the idle state the needs to
      be transitioned to and maintains a whole of heuristics including
      io load, previous idle states predictions etc for the same, based on
      which idle state entry decision is taken.
      
      With this fix, of setting target_residency of snooze to 0
      					     nap to smt_snooze_delay
      if the predicted idle time is less
      than smt_snooze_delay (target_residency of nap)
      value governor would pick snooze state, else nap. This adhers to the
      previous native idle design.
      Signed-off-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      83dac594
    • D
      cpuidle/powerpc: Fix smt_snooze_delay functionality. · 8ea959a1
      Deepthi Dharwar 提交于
      smt_snooze_delay was designed to  delay idle loop's nap entry
      in the native idle code before it got  ported over to use as part of
      the cpuidle framework.
      
      A -ve value  assigned to smt_snooze_delay should result in
      busy looping, in other words disabling the entry to nap state.
      
      	- https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-May/082450.html
      
      This particular functionality can be achieved currently by
      echo 1 > /sys/devices/system/cpu/cpu*/state1/disable
      but it is broken when one assigns -ve value to  the smt_snooze_delay
      variable either via sysfs entry or ppc64_cpu util.
      
      This patch aims to fix this, by disabling nap state when smt_snooze_delay
      variable is set to -ve value.
      Signed-off-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8ea959a1
    • D
      cpuidle/powerpc: Fix target residency initialisation in pseries cpuidle · 817deb05
      Deepthi Dharwar 提交于
      Remove the redundant target residency initialisation in pseries_cpuidle_driver_init().
      This is currently over-writing the residency time updated as part of the static
      table, resulting in  all the idle states having the same target
      residency of 100us which is incorrect. This may result in the menu governor making
      wrong state decisions.
      Signed-off-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      817deb05
    • A
      powerpc: Build fix for powerpc KVM · ce236ab5
      Aneesh Kumar K.V 提交于
      Fix build failure for powerpc KVM by adding missing VPN_SHIFT definition
      and the ';'
      
      arch/powerpc/kvm/book3s_32_mmu_host.c: In function 'kvmppc_mmu_map_page':
      arch/powerpc/kvm/book3s_32_mmu_host.c:176: error: 'VPN_SHIFT' undeclared (first use in this function)
      arch/powerpc/kvm/book3s_32_mmu_host.c:176: error: (Each undeclared identifier is reported only once
      arch/powerpc/kvm/book3s_32_mmu_host.c:176: error: for each function it appears in.)
      arch/powerpc/kvm/book3s_32_mmu_host.c:178: error: expected ';' before 'next_pteg'
      arch/powerpc/kvm/book3s_32_mmu_host.c:190: error: label 'next_pteg' used but not defined
      make[1]: *** [arch/powerpc/kvm/book3s_32_mmu_host.o] Error 1
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ce236ab5
    • B
      Revert "powerpc/perf: Use pmc_overflow() to detect rolled back events" · 72523d80
      Benjamin Herrenschmidt 提交于
      This reverts commit 81331211.
      
      This revert was requested by the author of the patch as it seems
      to cause system hangs with some low frequency events
      72523d80
  3. 17 10月, 2012 20 次提交
  4. 16 10月, 2012 1 次提交
  5. 15 10月, 2012 5 次提交
    • R
      ARM: fix oops on initial entry to userspace with Thumb2 kernels · 68687c84
      Russell King 提交于
      Daniel Mack reports an oops at boot with the latest kernels:
      
        Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2
        Modules linked in:
        CPU: 0    Not tainted  (3.6.0-11057-g584df1d #145)
        PC is at cpsw_probe+0x45a/0x9ac
        LR is at trace_hardirqs_on_caller+0x8f/0xfc
        pc : [<c03493de>]    lr : [<c005e81f>]    psr: 60000113
        sp : cf055fb0  ip : 00000000  fp : 00000000
        r10: 00000000  r9 : 00000000  r8 : 00000000
        r7 : 00000000  r6 : 00000000  r5 : c0344555  r4 : 00000000
        r3 : cf057a40  r2 : 00000000  r1 : 00000001  r0 : 00000000
        Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment user
        Control: 50c5387d  Table: 8f3f4019  DAC: 00000015
        Process init (pid: 1, stack limit = 0xcf054240)
        Stack: (0xcf055fb0 to 0xcf056000)
        5fa0:                                     00000001 00000000 00000000 00000000
        5fc0: cf055fb0 c000d1a8 00000000 00000000 00000000 00000000 00000000 00000000
        5fe0: 00000000 be9b3f10 00000000 b6f6add0 00000010 00000000 aaaabfaf a8babbaa
      
      The analysis of this is as follows.  In init/main.c, we issue:
      
      	kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
      
      This creates a new thread, which falls through to the ret_from_fork
      assembly, with r4 set NULL and r5 set to kernel_init.  You can see
      this in your oops dump register set - r5 is 0xc0344555, which is the
      address of kernel_init plus 1 which marks the function as Thumb code.
      
      Now, let's look at this code a little closer - this is what the
      disassembly looks like:
      
        c000d180 <ret_from_fork>:
        c000d180:       f03a fe08       bl      c0047d94 <schedule_tail>
        c000d184:       2d00            cmp     r5, #0
        c000d186:       bf1e            ittt    ne
        c000d188:       4620            movne   r0, r4
        c000d18a:       46fe            movne   lr, pc <-- XXXXXXX
        c000d18c:       46af            movne   pc, r5
        c000d18e:       46e9            mov     r9, sp
        c000d190:       ea4f 3959       mov.w   r9, r9, lsr #13
        c000d194:       ea4f 3949       mov.w   r9, r9, lsl #13
        c000d198:       e7c8            b.n     c000d12c <ret_to_user>
        c000d19a:       bf00            nop
        c000d19c:       f3af 8000       nop.w
      
      This code was introduced in 9fff2fa0 (arm: switch to saner
      kernel_execve() semantics).  I have marked one instruction, and it's
      the significant one - I'll come back to that later.
      
      Eventually, having had a successful call to kernel_execve(), kernel_init()
      returns zero.
      
      In returning, it uses the value in 'lr' which was set by the instruction
      I marked above.  Unfortunately, this causes lr to contain 0xc000d18e -
      an even address.  This switches the ISA to ARM on return but with a non
      word aligned PC value.
      
      So, what do we end up executing?  Well, not the instructions above - yes
      the opcodes, but they don't mean the same thing in ARM mode.  In ARM mode,
      it looks like this instead:
      
        c000d18c:       46e946af        strbtmi r4, [r9], pc, lsr #13
        c000d190:       3959ea4f        ldmdbcc r9, {r0, r1, r2, r3, r6, r9, fp, sp, lr, pc}^
        c000d194:       3949ea4f        stmdbcc r9, {r0, r1, r2, r3, r6, r9, fp, sp, lr, pc}^
        c000d198:       bf00e7c8        svclt   0x0000e7c8
        c000d19c:       8000f3af        andhi   pc, r0, pc, lsr #7
        c000d1a0:       e88db092        stm     sp, {r1, r4, r7, ip, sp, pc}
        c000d1a4:       46e81fff                        ; <UNDEFINED> instruction: 0x46e81fff
        c000d1a8:       8a00f3ef        bhi     0xc004a16c
        c000d1ac:       0a0cf08a        beq     0xc03493dc
      
      I have included more above, because it's relevant.  The PSR flags which
      we can see in the oops dump are nZCv, so Z and C are set.
      
      All the above ARM instructions are not executed, except for two.
      c000d1a0, which has no writeback, and writes below the current stack
      pointer (and that data is lost when we take the next exception.) The
      other instruction which is executed is c000d1ac, which takes us to...
      0xc03493dc.  However, remember that bit 1 of the PC got set.  So that
      makes the PC value 0xc03493de.
      
      And that value is the value we find in the oops dump for PC.  What is
      the instruction here when interpreted in ARM mode?
      
             0:       f71e150c                ; <UNDEFINED> instruction: 0xf71e150c
      
      and there we have our undefined instruction (remember that the 'never'
      condition code, 0xf, has been deprecated and is now always executed as
      it is now being used for additional instructions.)
      
      This path also nicely explains the state of the stack we see in the oops
      dump too.
      
      The above is a consistent and sane story for how we got to the oops
      dump, which all stems from the instruction at 0xc000d18a being wrong.
      Reported-by: NDaniel Mack <zonque@gmail.com>
      Tested-by: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      68687c84
    • A
      pinctrl: sirf: remove sirfsoc_gpio_set_pull function · 7bec2074
      Arnd Bergmann 提交于
      The prima2 platform advertises needing no mach/gpio.h header file,
      but its pinctrl driver now has a sirfsoc_gpio_set_pull function
      that uses constants defined in arch/arm/mach-prima2/include/mach/gpio.h,
      which fails to build.
      
      Fortunately, the sirfsoc_gpio_set_pull is not used anywhere in the
      kernel, so we can safely remove it. Any out of tree drivers using
      it will have to be converted to use proper pinctrl functions to
      do the same.
      
      Without this patch, building prima2_defconfig results in:
      
      drivers/pinctrl/pinctrl-sirf.c: In function 'sirfsoc_gpio_set_pull':
      drivers/pinctrl/pinctrl-sirf.c:1331:7: error: 'SIRFSOC_GPIO_PULL_NONE' undeclared (first use in this function)
      drivers/pinctrl/pinctrl-sirf.c:1331:7: note: each undeclared identifier is reported only once for each function it appears in
      drivers/pinctrl/pinctrl-sirf.c:1334:7: error: 'SIRFSOC_GPIO_PULL_UP' undeclared (first use in this function)
      drivers/pinctrl/pinctrl-sirf.c:1338:7: error: 'SIRFSOC_GPIO_PULL_DOWN' undeclared (first use in this function)
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NBarry Song <Baohua.Song@csr.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      7bec2074
    • P
      sh: Wire up kcmp syscall. · cf759932
      Paul Mundt 提交于
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      cf759932
    • D
      sparc64: Like x86 we should check current->mm during perf backtrace generation. · 08280e6c
      David S. Miller 提交于
      If the MM is not active, only report the top-level PC.  Do not try to
      access the address space.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08280e6c
    • M
      x86, boot: Explicitly include autoconf.h for hostprogs · b6eea87f
      Matt Fleming 提交于
      The hostprogs need access to the CONFIG_* symbols found in
      include/generated/autoconf.h.  But commit abbf1590 ("UAPI: Partition
      the header include path sets and add uapi/ header directories") replaced
      $(LINUXINCLUDE) with $(USERINCLUDE) which doesn't contain the necessary
      include paths.
      
      This has the undesirable effect of breaking the EFI boot stub because
      the #ifdef CONFIG_EFI_STUB code in arch/x86/boot/tools/build.c is
      never compiled.
      
      It should also be noted that because $(USERINCLUDE) isn't exported by
      the top-level Makefile it's actually empty in arch/x86/boot/Makefile.
      
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b6eea87f
  6. 14 10月, 2012 3 次提交
  7. 13 10月, 2012 2 次提交
    • J
      vfs: define struct filename and have getname() return it · 91a27b2a
      Jeff Layton 提交于
      getname() is intended to copy pathname strings from userspace into a
      kernel buffer. The result is just a string in kernel space. It would
      however be quite helpful to be able to attach some ancillary info to
      the string.
      
      For instance, we could attach some audit-related info to reduce the
      amount of audit-related processing needed. When auditing is enabled,
      we could also call getname() on the string more than once and not
      need to recopy it from userspace.
      
      This patchset converts the getname()/putname() interfaces to return
      a struct instead of a string. For now, the struct just tracks the
      string in kernel space and the original userland pointer for it.
      
      Later, we'll add other information to the struct as it becomes
      convenient.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      91a27b2a
    • C
      arch/tile: enable interrupts in do_work_pending() · c19c6c95
      Chris Metcalf 提交于
      All the called functions expect interrupts to be enabled, and
      now one of them has started to warn about it, so make it correct.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      c19c6c95