1. 17 6月, 2009 2 次提交
    • L
      printk: Add KERN_DEFAULT printk log-level · e28d7137
      Linus Torvalds 提交于
      This adds a KERN_DEFAULT loglevel marker, for when you cannot decide
      which loglevel you want, and just want to keep an existing printk
      with the default loglevel.
      
      The difference between having KERN_DEFAULT and having no log-level
      marker at all is two-fold:
      
       - having the log-level marker will now force a new-line if the
         previous printout had not added one (perhaps because it forgot,
         but perhaps because it expected a continuation)
      
       - having a log-level marker is required if you are printing out a
         message that otherwise itself could perhaps otherwise be mistaken
         for a log-level.
      Signed-of-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e28d7137
    • L
      printk: clean up handling of log-levels and newlines · 5fd29d6c
      Linus Torvalds 提交于
      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: NArjan van de Ven <arjan@infradead.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5fd29d6c
  2. 03 4月, 2009 1 次提交
  3. 17 3月, 2009 1 次提交
    • G
      printk: correct the behavior of printk_timed_ratelimit() · f2d28a2e
      Guillaume Knispel 提交于
      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
      example.
      
      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
      ticks).
      
      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: NGuillaume 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: NIngo Molnar <mingo@elte.hu>
      f2d28a2e
  4. 22 2月, 2009 1 次提交
    • A
      PM: Fix suspend_console and resume_console to use only one semaphore · 403f3075
      Arve Hjønnevåg 提交于
      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: NArve Hjønnevåg <arve@android.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Greg KH <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      403f3075
  5. 14 1月, 2009 2 次提交
  6. 06 1月, 2009 1 次提交
  7. 20 12月, 2008 1 次提交
  8. 24 10月, 2008 1 次提交
  9. 17 10月, 2008 3 次提交
  10. 14 10月, 2008 1 次提交
  11. 20 8月, 2008 2 次提交
    • J
      printk: robustify printk, update comment · 1fa63a81
      Jiri Kosina 提交于
      Remove the comment describing the possibility of printk() deadlocking on
      runqueue lock.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1fa63a81
    • P
      printk: robustify printk, fix #2 · fa33507a
      Peter Zijlstra 提交于
      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: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Reported-by: NDmitry Adamushko <dmitry.adamushko@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fa33507a
  12. 11 8月, 2008 1 次提交
  13. 31 7月, 2008 1 次提交
  14. 26 7月, 2008 1 次提交
    • D
      printk ratelimiting rewrite · 717115e1
      Dave Young 提交于
      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: NDave 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      717115e1
  15. 25 7月, 2008 1 次提交
  16. 09 7月, 2008 1 次提交
  17. 08 7月, 2008 1 次提交
  18. 18 6月, 2008 1 次提交
  19. 16 6月, 2008 1 次提交
  20. 27 5月, 2008 1 次提交
    • M
      xen: Enable console tty by default in domU if it's not a dummy · 9e124fe1
      Markus Armbruster 提交于
      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: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9e124fe1
  21. 25 5月, 2008 6 次提交
  22. 24 5月, 2008 1 次提交
    • S
      ftrace: trace irq disabled critical timings · 81d68a96
      Steven Rostedt 提交于
      This patch adds latency tracing for critical timings
      (how long interrupts are disabled for).
      
       "irqsoff" is added to /debugfs/tracing/available_tracers
      
      Note:
        tracing_max_latency
          also holds the max latency for irqsoff (in usecs).
         (default to large number so one must start latency tracing)
      
        tracing_thresh
          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: NIngo 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)
      
      vim:ft=help
      =======
      
      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)
      
      vim:ft=help
      =======
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      81d68a96
  23. 30 4月, 2008 3 次提交
  24. 29 4月, 2008 1 次提交
  25. 16 4月, 2008 1 次提交
  26. 25 3月, 2008 1 次提交
  27. 26 2月, 2008 1 次提交
  28. 09 2月, 2008 1 次提交