1. 21 5月, 2010 2 次提交
  2. 07 3月, 2010 1 次提交
  3. 04 2月, 2010 2 次提交
  4. 01 1月, 2010 1 次提交
  5. 18 12月, 2009 1 次提交
  6. 02 12月, 2009 1 次提交
  7. 30 11月, 2009 1 次提交
  8. 23 10月, 2009 1 次提交
    • C
      ratelimit: Make suppressed output messages more useful · 5c828713
      Christian Borntraeger 提交于
      Today I got:
      
        [39648.224782] Registered led device: iwl-phy0::TX
        [40676.545099] __ratelimit: 246 callbacks suppressed
        [40676.545103] abcdef[23675]: segfault at 0 ...
      
      as you can see the ratelimit message contains a function prefix.
      Since this is always __ratelimit, this wont help much.
      
      This patch changes __ratelimit and printk_ratelimit to print the
      function name that calls ratelimit.
      
      This will pinpoint the responsible function, as long as not several
      different places call ratelimit with the same ratelimit state at
      the same time. In that case we catch only one random function that
      calls ratelimit after the wait period.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Cc: Dave Young <hidave.darkstar@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      CC: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <200910231458.11832.borntraeger@de.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5c828713
  9. 23 9月, 2009 2 次提交
  10. 22 9月, 2009 1 次提交
    • I
      printk: Remove ratelimit.h from kernel.h · 3fff4c42
      Ingo Molnar 提交于
      Decouple kernel.h from ratelimit.h: the global declaration of
      printk's ratelimit_state is not needed, and it leads to messy
      circular dependencies due to ratelimit.h's (new) adding of a
      spinlock_types.h include.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: David S. Miller <davem@davemloft.net>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3fff4c42
  11. 15 9月, 2009 1 次提交
  12. 09 8月, 2009 1 次提交
  13. 10 7月, 2009 2 次提交
    • F
      printk: Restore previous console_loglevel when re-enabling logging · 1aaad49e
      Frans Pop 提交于
      When logging to console is disabled from userspace using klogctl()
      and later re-enabled, console_loglevel gets set to the default
      log level instead to the previous value.
      
      This means that if the kernel was booted with 'quiet', the boot is
      suddenly no longer quiet after logging to console gets re-enabled.
      
      Save the current console_loglevel when logging is disabled and
      restore to that value. If the log level is set to a specific value
      while disabled, this is interpreted as an implicit re-enabling of
      the logging.
      
      The problem that prompted this patch is described in:
      
          http://lkml.org/lkml/2009/6/28/234
      
      There are two variations possible on the patch below:
      
       1) If klogctl(7) is called while logging is not disabled, then set level
          to default (partially preserving current functionality):
        	case 7:		/* Enable logging to console */
       -		console_loglevel = default_console_loglevel;
       +		if (saved_console_loglevel == -1)
       +			console_loglevel = default_console_loglevel;
       +		else {
       +			console_loglevel = saved_console_loglevel;
       +			saved_console_loglevel = -1;
       +		}
      
       2) If klogctl(8) is called while logging is disabled, then don't enable
          logging, but remember the requested value for when logging does get
          enabled again:
        	case 8:		/* Set level of messages printed to console */
       [...]
       - 		console_loglevel = len;
       +		if (saved_console_loglevel == -1)
       +			console_loglevel = len;
       +		else
       +			saved_console_loglevel = len;
      
      Yet another option would be to ignore the request.
      Signed-off-by: NFrans Pop <elendil@planet.nl>
      Cc: cryptsetup@packages.debian.org
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <200907061331.49930.elendil@planet.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1aaad49e
    • R
      printk: Ensure that "console enabled" messages are printed on the console · 8259cf43
      Robin Getz 提交于
      Today, when a console is registered without CON_PRINTBUFFER,
      end users never see the announcement of it being added, and
      never know if they missed something, if the console is really
      at the start or not, and just leads to general confusion.
      
      This re-orders existing code, to make sure the console is
      added, before the "console [%s%d] enabled" is printed out -
      ensuring that this message is _always_ seen.
      
      This has the desired/intended side effect of making sure that
      "console enabled:" messages are printed on the bootconsole, and
      the real console. This does cause the same line is printed
      twice if the bootconsole and real console are the same device,
      but if they are on different devices, the message is printed to
      both consoles.
      
      Signed-off-by : Robin Getz <rgetz@blackfin.uclinux.org>
      Cc: "Andrew Morton" <akpm@linux-foundation.org>
      Cc: "Linus Torvalds" <torvalds@linux-foundation.org>
      LKML-Reference: <200907091308.37370.rgetz@blackfin.uclinux.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8259cf43
  14. 03 7月, 2009 1 次提交
    • R
      printk: Enable the use of more than one CON_BOOT (early console) · 4d091611
      Robin Getz 提交于
      Today, register_console() assumes the following usage:
      
        - The first console to register with a flag set to CON_BOOT
          is the one and only bootconsole.
      
        - If another register_console() is called with an additional
          CON_BOOT, it is silently rejected.
      
        - As soon as a console without the CON_BOOT set calls
          registers the bootconsole is automatically unregistered.
      
        - Once there is a "real" console - register_console() will
          silently reject any consoles with it's CON_BOOT flag set.
      
      In many systems (alpha, blackfin, microblaze, mips, powerpc,
      sh, & x86), there are early_printk implementations, which use
      the CON_BOOT which come out serial ports, vga, usb, & memory
      buffers.
      
      In many embedded systems, it would be nice to have two
      bootconsoles - in case the primary fails, you always have
      access to a backup memory buffer - but this requires at least
      two CON_BOOT consoles...
      
      This patch enables that functionality.
      
      With the change applied, on boot you get (if you try to
      re-enable a boot console after the "real" console has been
      registered):
      
        root:/> dmesg | grep console
        bootconsole [early_shadow0] enabled
        bootconsole [early_BFuart0] enabled
        Kernel command line: root=/dev/mtdblock0 rw earlyprintk=serial,uart0,57600 console=ttyBF0,57600 nmi_debug=regs
        console handover:boot [early_BFuart0] boot [early_shadow0]  -> real [ttyBF0]
        Too late to register bootconsole early_shadow0
      
      or:
      
        root:/> dmesg | grep console
        Kernel command line: root=/dev/mtdblock0 rw console=ttyBF0,57600
        console [ttyBF0] enabled
      Signed-off-by: NRobin Getz <rgetz@blackfin.uclinux.org>
      Cc: "Linus Torvalds" <torvalds@linux-foundation.org>
      Cc: "Andrew Morton" <akpm@linux-foundation.org>
      Cc: "Mike Frysinger" <vapier.adi@gmail.com>
      Cc: "Paul Mundt" <lethal@linux-sh.org>
      LKML-Reference: <200907012108.38030.rgetz@blackfin.uclinux.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4d091611
  15. 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
  16. 03 4月, 2009 1 次提交
  17. 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
  18. 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
  19. 14 1月, 2009 2 次提交
  20. 06 1月, 2009 1 次提交
  21. 20 12月, 2008 1 次提交
  22. 24 10月, 2008 1 次提交
  23. 17 10月, 2008 3 次提交
  24. 14 10月, 2008 1 次提交
  25. 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
  26. 11 8月, 2008 1 次提交
  27. 31 7月, 2008 1 次提交
  28. 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
  29. 25 7月, 2008 1 次提交
  30. 09 7月, 2008 1 次提交
  31. 08 7月, 2008 1 次提交