1. 16 Jun, 2009 1 commit
    • Linus Torvalds's avatar
      printk: clean up handling of log-levels and newlines · 5fd29d6c
      Linus Torvalds authored
      It used to be that we would only look at the log-level in a printk()
      after explicit newlines, which can cause annoying problems when the
      previous printk() did not end with a '\n'. In that case, the log-level
      marker would be just printed out in the middle of the line, and be
      seen as just noise rather than change the logging level.
      This changes things to always look at the log-level in the first
      bytes of the printout. If a log level marker is found, it is always
      used as the log-level. Additionally, if no newline existed, one is
      added (unless the log-level is the explicit KERN_CONT marker, to
      explicitly show that it's a continuation of a previous line).
      Acked-by: default avatarArjan van de Ven <arjan@infradead.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  2. 02 Apr, 2009 1 commit
    • Neil Horman's avatar
      kexec: add dmesg log symbols to /proc/vmcoreinfo lists · 04d491ab
      Neil Horman authored
      It would be nice to be able to extract the dmesg log from a vmcore file
      without needing to keep the debug symbols for the running kernel handy all
      the time.  We have a facility to do this in /proc/vmcore.  This patch adds
      the log_buf and log_end symbols to the vmcoreinfo area so that tools (like
      makedumpfile) can easily extract the dmesg logs from a vmcore image.
      [akpm@linux-foundation.org: several fixes and cleanups]
      [akpm@linux-foundation.org: fix unused log_buf_kexec_setup()]
      [akpm@linux-foundation.org: build fix]
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Cc: Simon Horman <horms@verge.net.au>
      Acked-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  3. 17 Mar, 2009 1 commit
    • Guillaume Knispel's avatar
      printk: correct the behavior of printk_timed_ratelimit() · f2d28a2e
      Guillaume Knispel authored
      Impact: fix jiffies-comparison sign-wrap behavior
      The behavior provided by printk_timed_ratelimit() is, in some
      situations, probably not what a caller would reasonably expect:
      bool printk_timed_ratelimit(unsigned long *caller_jiffies,
      			unsigned int interval_msecs)
      	if (*caller_jiffies == 0 || time_after(jiffies, *caller_jiffies)) {
      		*caller_jiffies = jiffies + msecs_to_jiffies(interval_msecs);
      		return true;
      	return false;
      On a 32 bit computer, if printk_timed_ratelimit() is initially called at
      time jiffies == Ja, *caller_jiffies is set to
      Ja + msecs_to_jiffies(interval_msecs): let's say Ja + 42 for this
      If this caller then doesn't call printk_timed_ratelimit() until
      jiffies == Ja + (1 << 31) + 42 (which can happen as soon as ~ 25 days
      later on a 1000 HZ system), printk_timed_ratelimit() will then always
      return false to this caller until jiffies loops completely (1 << 31 more
      Ths change makes it only return false if jiffies is in the small
      time window starting at the previous call when true was returned and
      ending interval_msecs later.  Note that if jiffies loops completely
      between two calls to printk_timed_ratelimit(), it will obviously still
      wrongly return false, but this is something with a low probability.
      If something completely reliable is needed I guess jiffies_64 must be
      used (which this change does not do).
      Signed-off-by: default avatarGuillaume Knispel <gknispel@proformatique.com>
      Cc: Ulrich Drepper <drepper@redhat.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@osdl.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20090317161842.0059096b@xilun.lan.proformatique.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  4. 21 Feb, 2009 1 commit
    • Arve Hjønnevåg's avatar
      PM: Fix suspend_console and resume_console to use only one semaphore · 403f3075
      Arve Hjønnevåg authored
      This fixes a race where a thread acquires the console while the
      console is suspended, and the console is resumed before this
      thread releases it. In this case, the secondary console
      semaphore would be left locked, and the primary semaphore would
      be released twice. This in turn would cause the console switch
      on suspend or resume to hang forever.
      Note that suspend_console does not actually lock the console
      for clients that use acquire_console_sem, it only locks it for
      clients that use try_acquire_console_sem. If we change
      suspend_console to fully lock the console, then the kernel
      may deadlock on suspend. One client of try_acquire_console_sem
      is acquire_console_semaphore_for_printk, which uses it to
      prevent printk from using the console while it is suspended.
      Signed-off-by: default avatarArve Hjønnevåg <arve@android.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Greg KH <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 14 Jan, 2009 2 commits
  6. 06 Jan, 2009 1 commit
  7. 19 Dec, 2008 1 commit
  8. 23 Oct, 2008 1 commit
  9. 16 Oct, 2008 3 commits
  10. 13 Oct, 2008 1 commit
  11. 20 Aug, 2008 2 commits
    • Jiri Kosina's avatar
      printk: robustify printk, update comment · 1fa63a81
      Jiri Kosina authored
      Remove the comment describing the possibility of printk() deadlocking on
      runqueue lock.
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Peter Zijlstra's avatar
      printk: robustify printk, fix #2 · fa33507a
      Peter Zijlstra authored
      Dmitry Adamushko reported:
      > [*] btw., with DEBUG being enabled, pr_debug() generates [1] when
      > debug_smp_processor_id() is used (CONFIG_DEBUG_PREEMPT).
      > the problem seems to be caused by the following commit:
      > commit b845b517
      > Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
      > Date:   Fri Aug 8 21:47:09 2008 +0200
      >     printk: robustify printk
      > wake_up_klogd() -> __get_cpu_var() -> smp_processor_id()
      > and that's being called from release_console_sem() which is, in turn,
      > said to be "may be called from any context" [2]
      > and in this case, it seems to be called from some non-preemptible
      > context (although, it can't be printk()...
      > although, I haven't looked carefully yet).
      > Provided [2], __get_cpu_var() is perhaps not the right solution there.
      > [1]
      > [ 7697.942005] BUG: using smp_processor_id() in preemptible [00000000] code: syslogd/3542
      > [ 7697.942005] caller is wake_up_klogd+0x1b/0x50
      > [ 7697.942005] Pid: 3542, comm: syslogd Not tainted 2.6.27-rc3-tip-git #2
      > [ 7697.942005] Call Trace:
      > [ 7697.942005]  [<ffffffff8036b398>] debug_smp_processor_id+0xe8/0xf0
      > [ 7697.942005]  [<ffffffff80239d3b>] wake_up_klogd+0x1b/0x50
      > [ 7697.942005]  [<ffffffff8023a047>] release_console_sem+0x1e7/0x200
      > [ 7697.942005]  [<ffffffff803c0f17>] do_con_write+0xb7/0x1f30
      > [ 7697.942005]  [<ffffffff8020d920>] ? show_trace+0x10/0x20
      > [ 7697.942005]  [<ffffffff8020dc42>] ? dump_stack+0x72/0x80
      > [ 7697.942005]  [<ffffffff8036392d>] ? __ratelimit+0xbd/0xe0
      > [ 7697.942005]  [<ffffffff8036b398>] ? debug_smp_processor_id+0xe8/0xf0
      > [ 7697.942005]  [<ffffffff80239d3b>] ? wake_up_klogd+0x1b/0x50
      > [ 7697.942005]  [<ffffffff8023a047>] ? release_console_sem+0x1e7/0x200
      > [ 7697.942005]  [<ffffffff803c2de9>] con_write+0x19/0x30
      > [ 7697.942005]  [<ffffffff803b37b6>] write_chan+0x276/0x3c0
      > [ 7697.942005]  [<ffffffff80232b20>] ? default_wake_function+0x0/0x10
      > [ 7697.942005]  [<ffffffff804cb872>] ? _spin_lock_irqsave+0x22/0x50
      > [ 7697.942005]  [<ffffffff803b1334>] tty_write+0x194/0x260
      > [ 7697.942005]  [<ffffffff803b3540>] ? write_chan+0x0/0x3c0
      > [ 7697.942005]  [<ffffffff803b14a4>] redirected_tty_write+0xa4/0xb0
      > [ 7697.942005]  [<ffffffff803b1400>] ? redirected_tty_write+0x0/0xb0
      > [ 7697.942005]  [<ffffffff802a88c2>] do_loop_readv_writev+0x52/0x80
      > [ 7697.942005]  [<ffffffff802a939d>] do_readv_writev+0x1bd/0x1d0
      > [ 7697.942005]  [<ffffffff802a93e9>] vfs_writev+0x39/0x60
      > [ 7697.942005]  [<ffffffff802a9870>] sys_writev+0x50/0x90
      > [ 7697.942005]  [<ffffffff8020bb3b>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Reported-by: default avatarDmitry Adamushko <dmitry.adamushko@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  12. 11 Aug, 2008 1 commit
  13. 30 Jul, 2008 1 commit
  14. 25 Jul, 2008 1 commit
    • Dave Young's avatar
      printk ratelimiting rewrite · 717115e1
      Dave Young authored
      All ratelimit user use same jiffies and burst params, so some messages
      (callbacks) will be lost.
      For example:
      a call printk_ratelimit(5 * HZ, 1)
      b call printk_ratelimit(5 * HZ, 1) before the 5*HZ timeout of a, then b will
      will be supressed.
      - rewrite __ratelimit, and use a ratelimit_state as parameter.  Thanks for
        hints from andrew.
      - Add WARN_ON_RATELIMIT, update rcupreempt.h
      - remove __printk_ratelimit
      - use __ratelimit in net_ratelimit
      Signed-off-by: default avatarDave Young <hidave.darkstar@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
      Cc: Dave Young <hidave.darkstar@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  15. 24 Jul, 2008 1 commit
  16. 08 Jul, 2008 2 commits
  17. 18 Jun, 2008 1 commit
  18. 16 Jun, 2008 1 commit
  19. 27 May, 2008 1 commit
    • Markus Armbruster's avatar
      xen: Enable console tty by default in domU if it's not a dummy · 9e124fe1
      Markus Armbruster authored
      Without console= arguments on the kernel command line, the first
      console to register becomes enabled and the preferred console (the one
      behind /dev/console).  This is normally tty (assuming
      CONFIG_VT_CONSOLE is enabled, which it commonly is).
      This is okay as long tty is a useful console.  But unless we have the
      PV framebuffer, and it is enabled for this domain, tty0 in domU is
      merely a dummy.  In that case, we want the preferred console to be the
      Xen console hvc0, and we want it without having to fiddle with the
      kernel command line.  Commit b8c2d3df
      did that for us.
      Since we now have the PV framebuffer, we want to enable and prefer tty
      again, but only when PVFB is enabled.  But even then we still want to
      enable the Xen console as well.
      Problem: when tty registers, we can't yet know whether the PVFB is
      enabled.  By the time we can know (xenstore is up), the console setup
      game is over.
      Solution: enable console tty by default, but keep hvc as the preferred
      console.  Change the preferred console to tty when PVFB probes
      successfully, unless we've been given console kernel parameters.
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  20. 24 May, 2008 6 commits
  21. 23 May, 2008 1 commit
    • Steven Rostedt's avatar
      ftrace: trace irq disabled critical timings · 81d68a96
      Steven Rostedt authored
      This patch adds latency tracing for critical timings
      (how long interrupts are disabled for).
       "irqsoff" is added to /debugfs/tracing/available_tracers
          also holds the max latency for irqsoff (in usecs).
         (default to large number so one must start latency tracing)
          threshold (in usecs) to always print out if irqs off
          is detected to be longer than stated here.
          If irq_thresh is non-zero, then max_irq_latency
          is ignored.
      Here's an example of a trace with ftrace_enabled = 0
      preemption latency trace v1.1.5 on 2.6.24-rc7
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
       latency: 100 us, #3/3, CPU#1 | (M:rt VP:0, KP:0, SP:0 HP:0 #P:2)
          | task: swapper-0 (uid:0 nice:0 policy:0 rt_prio:0)
       => started at: _spin_lock_irqsave+0x2a/0xb7
       => ended at:   _spin_unlock_irqrestore+0x32/0x5f
                       _------=> CPU#
                      / _-----=> irqs-off
                     | / _----=> need-resched
                     || / _---=> hardirq/softirq
                     ||| / _--=> preempt-depth
                     |||| /
                     |||||     delay
         cmd     pid ||||| time  |   caller
            \   /    |||||   \   |   /
       swapper-0     1d.s3    0us+: _spin_lock_irqsave+0x2a/0xb7 (e1000_update_stats+0x47/0x64c [e1000])
       swapper-0     1d.s3  100us : _spin_unlock_irqrestore+0x32/0x5f (e1000_update_stats+0x641/0x64c [e1000])
       swapper-0     1d.s3  100us : trace_hardirqs_on_caller+0x75/0x89 (_spin_unlock_irqrestore+0x32/0x5f)
      And this is a trace with ftrace_enabled == 1
      preemption latency trace v1.1.5 on 2.6.24-rc7
       latency: 102 us, #12/12, CPU#1 | (M:rt VP:0, KP:0, SP:0 HP:0 #P:2)
          | task: swapper-0 (uid:0 nice:0 policy:0 rt_prio:0)
       => started at: _spin_lock_irqsave+0x2a/0xb7
       => ended at:   _spin_unlock_irqrestore+0x32/0x5f
                       _------=> CPU#
                      / _-----=> irqs-off
                     | / _----=> need-resched
                     || / _---=> hardirq/softirq
                     ||| / _--=> preempt-depth
                     |||| /
                     |||||     delay
         cmd     pid ||||| time  |   caller
            \   /    |||||   \   |   /
       swapper-0     1dNs3    0us+: _spin_lock_irqsave+0x2a/0xb7 (e1000_update_stats+0x47/0x64c [e1000])
       swapper-0     1dNs3   46us : e1000_read_phy_reg+0x16/0x225 [e1000] (e1000_update_stats+0x5e2/0x64c [e1000])
       swapper-0     1dNs3   46us : e1000_swfw_sync_acquire+0x10/0x99 [e1000] (e1000_read_phy_reg+0x49/0x225 [e1000])
       swapper-0     1dNs3   46us : e1000_get_hw_eeprom_semaphore+0x12/0xa6 [e1000] (e1000_swfw_sync_acquire+0x36/0x99 [e1000])
       swapper-0     1dNs3   47us : __const_udelay+0x9/0x47 (e1000_read_phy_reg+0x116/0x225 [e1000])
       swapper-0     1dNs3   47us+: __delay+0x9/0x50 (__const_udelay+0x45/0x47)
       swapper-0     1dNs3   97us : preempt_schedule+0xc/0x84 (__delay+0x4e/0x50)
       swapper-0     1dNs3   98us : e1000_swfw_sync_release+0xc/0x55 [e1000] (e1000_read_phy_reg+0x211/0x225 [e1000])
       swapper-0     1dNs3   99us+: e1000_put_hw_eeprom_semaphore+0x9/0x35 [e1000] (e1000_swfw_sync_release+0x50/0x55 [e1000])
       swapper-0     1dNs3  101us : _spin_unlock_irqrestore+0xe/0x5f (e1000_update_stats+0x641/0x64c [e1000])
       swapper-0     1dNs3  102us : _spin_unlock_irqrestore+0x32/0x5f (e1000_update_stats+0x641/0x64c [e1000])
       swapper-0     1dNs3  102us : trace_hardirqs_on_caller+0x75/0x89 (_spin_unlock_irqrestore+0x32/0x5f)
      Signed-off-by: default avatarSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  22. 30 Apr, 2008 3 commits
  23. 29 Apr, 2008 1 commit
  24. 15 Apr, 2008 1 commit
  25. 24 Mar, 2008 1 commit
  26. 26 Feb, 2008 1 commit
  27. 08 Feb, 2008 2 commits