1. 18 7月, 2012 7 次提交
  2. 12 7月, 2012 7 次提交
  3. 05 7月, 2012 1 次提交
  4. 01 7月, 2012 9 次提交
  5. 30 6月, 2012 9 次提交
  6. 29 6月, 2012 7 次提交
    • K
      printk: flush continuation lines immediately to console · 084681d1
      Kay Sievers 提交于
      Continuation lines are buffered internally, intended to merge the
      chunked printk()s into a single record, and to isolate potentially
      racy continuation users from usual terminated line users.
      
      This though, has the effect that partial lines are not printed to
      the console in the moment they are emitted. In case the kernel
      crashes in the meantime, the potentially interesting printed
      information would never reach the consoles.
      
      Here we share the continuation buffer with the console copy logic,
      and partial lines are always immediately flushed to the available
      consoles. They are still buffered internally to improve the
      readability and integrity of the messages and minimize the amount
      of needed record headers to store.
      Signed-off-by: NKay Sievers <kay@vrfy.org>
      Tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      084681d1
    • M
      powerpc/pseries: Fix software invalidate TCE · bc6dc752
      Michael Neuling 提交于
      The following added support for powernv but broke pseries/BML:
       1f1616e8 powerpc/powernv: Add TCE SW invalidation support
      
      TCE_PCI_SW_INVAL was split into FREE and CREATE flags but the tests in
      the pseries code were not updated to reflect this.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      cc: stable@kernel.org [v3.3+]
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      bc6dc752
    • A
      powerpc: check_and_cede_processor() never cedes · 0b17ba72
      Anton Blanchard 提交于
      Commit f948501b ("Make hard_irq_disable() actually hard-disable
      interrupts") caused check_and_cede_processor to stop working.
      ->irq_happened will never be zero right after a hard_irq_disable
      so the compiler removes the call to cede_processor completely.
      
      The bug was introduced back in the lazy interrupt handling rework
      of 3.4 but was hidden until recently because hard_irq_disable did
      nothing.
      
      This issue will eventually appear in 3.4 stable since the
      hard_irq_disable fix is marked stable, so mark this one for stable
      too.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      0b17ba72
    • S
      powerpc/ftrace: Do not trace restore_interrupts() · 2d773aa4
      Steven Rostedt 提交于
      As I was adding code that affects all archs, I started testing function
      tracer against PPC64 and found that it currently locks up with 3.4
      kernel. I figured it was due to tracing a function that shouldn't be, so
      I went through the following process to bisect to find the culprit:
      
       cat /debug/tracing/available_filter_functions > t
       num=`wc -l t`
       sed -ne "1,${num}p" t > t1
       let num=num+1
       sed -ne "${num},$p" t > t2
       cat t1 > /debug/tracing/set_ftrace_filter
       echo function /debug/tracing/current_tracer
       <failed? bisect t1, if not bisect t2>
      
      It finally came down to this function: restore_interrupts()
      
      I'm not sure why this locks up the system. It just seems to prevent
      scheduling from occurring. Interrupts seem to still work, as I can ping
      the box. But all user processes freeze.
      
      When restore_interrupts() is not traced, function tracing works fine.
      
      Cc: stable@kernel.org
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2d773aa4
    • L
      powerpc: Fix Section mismatch warnings in prom_init.c · 2cb387ae
      Li Zhong 提交于
      This patches tries to fix a couple of Section mismatch warnings like
      following one:
      
      WARNING: arch/powerpc/kernel/built-in.o(.text+0x2923c): Section mismatch
      in reference from the function .prom_query_opal() to the
      function .init.text:.call_prom()
      The function .prom_query_opal() references
      the function __init .call_prom().
      This is often because .prom_query_opal lacks a __init
      annotation or the annotation of .call_prom is wrong.
      Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2cb387ae
    • T
      ppc64: fix missing to check all bits of _TIF_USER_WORK_MASK in preempt · c58ce2b1
      Tiejun Chen 提交于
      In entry_64.S version of ret_from_except_lite, you'll notice that
      in the !preempt case, after we've checked MSR_PR we test for any
      TIF flag in _TIF_USER_WORK_MASK to decide whether to go to do_work
      or not. However, in the preempt case, we do a convoluted trick to
      test SIGPENDING only if PR was set and always test NEED_RESCHED ...
      but we forget to test any other bit of _TIF_USER_WORK_MASK !!! So
      that means that with preempt, we completely fail to test for things
      like single step, syscall tracing, etc...
      
      This should be fixed as the following path:
      
       - Test PR. If not set, go to resume_kernel, else continue.
      
       - If go resume_kernel, to do that original do_work.
      
       - If else, then always test for _TIF_USER_WORK_MASK to decide to do
      that original user_work, else restore directly.
      Signed-off-by: NTiejun Chen <tiejun.chen@windriver.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c58ce2b1
    • M
      powerpc: Fix uninitialised error in numa.c · 82b2521d
      Michael Neuling 提交于
      chroma_defconfig currently gives me this with gcc 4.6:
        arch/powerpc/mm/numa.c:638:13: error: 'dm' may be used uninitialized in this function [-Werror=uninitialized]
      
      It's a bogus warning/error since of_get_drconf_memory() only writes it
      anyway.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      cc: <stable@kernel.org> [v3.3+]
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      82b2521d