1. 26 11月, 2010 1 次提交
  2. 16 11月, 2010 1 次提交
  3. 12 11月, 2010 1 次提交
  4. 27 10月, 2010 3 次提交
  5. 12 10月, 2010 1 次提交
  6. 10 8月, 2010 1 次提交
  7. 05 8月, 2010 1 次提交
    • K
      printk: fix delayed messages from CPU hotplug events · 034260d6
      Kevin Cernekee 提交于
      When a secondary CPU is being brought up, it is not uncommon for
      printk() to be invoked when cpu_online(smp_processor_id()) == 0.  The
      case that I witnessed personally was on MIPS:
      
      http://lkml.org/lkml/2010/5/30/4
      
      If (can_use_console() == 0), printk() will spool its output to log_buf
      and it will be visible in "dmesg", but that output will NOT be echoed to
      the console until somebody calls release_console_sem() from a CPU that
      is online.  Therefore, the boot time messages from the new CPU can get
      stuck in "limbo" for a long time, and might suddenly appear on the
      screen when a completely unrelated event (e.g. "eth0: link is down")
      occurs.
      
      This patch modifies the console code so that any pending messages are
      automatically flushed out to the console whenever a CPU hotplug
      operation completes successfully or aborts.
      
      The issue was seen on 2.6.34.
      
      Original patch by Kevin Cernekee with cleanups by akpm and additional fixes
      by Santosh Shilimkar.  This patch superseeds
      https://patchwork.linux-mips.org/patch/1357/.
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      To: <mingo@elte.hu>
      To: <akpm@linux-foundation.org>
      To: <simon.kagstrom@netinsight.net>
      To: <David.Woodhouse@intel.com>
      To: <lethal@linux-sh.org>
      Cc: <linux-kernel@vger.kernel.org>
      Cc: <linux-mips@linux-mips.org>
      Reviewed-by: NPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Patchwork: https://patchwork.linux-mips.org/patch/1534/
      LKML-Reference: <ede63b5a20af951c755736f035d1e787772d7c28@localhost>
      LKML-Reference: <EAF47CD23C76F840A9E7FCE10091EFAB02C5DB6D1F@dbde02.ent.ti.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      034260d6
  8. 21 5月, 2010 2 次提交
  9. 07 3月, 2010 1 次提交
  10. 04 2月, 2010 2 次提交
  11. 01 1月, 2010 1 次提交
  12. 18 12月, 2009 1 次提交
  13. 02 12月, 2009 1 次提交
  14. 30 11月, 2009 1 次提交
  15. 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
  16. 23 9月, 2009 2 次提交
  17. 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
  18. 15 9月, 2009 1 次提交
  19. 09 8月, 2009 1 次提交
  20. 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
  21. 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
  22. 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
  23. 03 4月, 2009 1 次提交
  24. 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
  25. 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
  26. 14 1月, 2009 2 次提交
  27. 06 1月, 2009 1 次提交
  28. 20 12月, 2008 1 次提交
  29. 24 10月, 2008 1 次提交
  30. 17 10月, 2008 3 次提交