23 Sep, 2009

2 commits

  • When syslog is not possible, at the same time there's no serial/net
    console available, it will be hard to read the printk messages. For
    example oops/panic/warning messages in shutdown phase.

    Add a printk delay feature, we can make each printk message delay some
    milliseconds.

    Setting the delay by proc/sysctl interface: /proc/sys/kernel/printk_delay

    The value range from 0 - 10000, default value is 0

    [akpm@linux-foundation.org: fix a few things]
    Signed-off-by: Dave Young
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Young
     
  • Rename `printk_delay_msec' to `loops_per_msec', because the patch "printk:
    add printk_delay to make messages readable for some scenarios" wishes to
    more appropriately use the `printk_delay_msec' identifier.

    [akpm@linux-foundation.org: add a comment]
    Signed-off-by: Dave Young
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Young
     

15 Sep, 2009

1 commit

  • console_print() is an old legacy interface mostly unused in the entire
    kernel tree. It's best to clean up its existing use and let developers
    use their own implementation of it as they feel fit.

    Signed-off-by: Anirban Sinha
    Signed-off-by: Linus Torvalds

    Anirban Sinha
     

09 Aug, 2009

1 commit


10 Jul, 2009

2 commits

  • 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: Frans Pop
    Cc: cryptsetup@packages.debian.org
    Cc: Andrew Morton
    Cc: Linus Torvalds
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frans Pop
     
  • 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
    Cc: "Andrew Morton"
    Cc: "Linus Torvalds"
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Robin Getz
     

03 Jul, 2009

1 commit

  • 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: Robin Getz
    Cc: "Linus Torvalds"
    Cc: "Andrew Morton"
    Cc: "Mike Frysinger"
    Cc: "Paul Mundt"
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Robin Getz
     

17 Jun, 2009

2 commits

  • 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: Linus Torvalds

    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: Arjan van de Ven
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

06 Apr, 2009

1 commit

  • * 'printk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    printk: correct the behavior of printk_timed_ratelimit()
    vsprintf: unify the format decoding layer for its 3 users, cleanup
    fix regression from "vsprintf: unify the format decoding layer for its 3 users"
    vsprintf: fix bug in negative value printing
    vsprintf: unify the format decoding layer for its 3 users
    vsprintf: add binary printf
    printk: introduce printk_once()

    Fix trivial conflicts (printk_once vs log_buf_kexec_setup() added near
    each other) in include/linux/kernel.h.

    Linus Torvalds
     

03 Apr, 2009

1 commit

  • 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: Neil Horman
    Cc: Simon Horman
    Acked-by: Vivek Goyal
    Cc: Neil Horman
    Cc: Simon Horman
    Cc: Vivek Goyal
    Cc: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Neil Horman
     

17 Mar, 2009

1 commit

  • 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: Guillaume Knispel
    Cc: Ulrich Drepper
    Cc: Rusty Russell
    Cc: Andrew Morton
    Cc: Linus Torvalds
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Guillaume Knispel
     

22 Feb, 2009

1 commit

  • 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: Arve Hjønnevåg
    Signed-off-by: Rafael J. Wysocki
    Cc: Len Brown
    Cc: Greg KH
    Signed-off-by: Linus Torvalds

    Arve Hjønnevåg
     

14 Jan, 2009

2 commits


06 Jan, 2009

1 commit


20 Dec, 2008

1 commit

  • Impact: fix truncated recursion bug message printout

    When recursion_bug is true, kernel discards original message because printk_buf
    contains recursion_bug_msg with NULL terminator. The sizeof(recursion_bug_msg)
    makes this, use strlen() to get correct length without NULL terminator.

    Reported-by: Toshikazu Nakayama
    Signed-off-by: Hiroshi Shimamoto
    Signed-off-by: Ingo Molnar

    Hiroshi Shimamoto
     

24 Oct, 2008

1 commit


17 Oct, 2008

3 commits

  • * 'core-v28-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    do_generic_file_read: s/EINTR/EIO/ if lock_page_killable() fails
    softirq, warning fix: correct a format to avoid a warning
    softirqs, debug: preemption check
    x86, pci-hotplug, calgary / rio: fix EBDA ioremap()
    IO resources, x86: ioremap sanity check to catch mapping requests exceeding, fix
    IO resources, x86: ioremap sanity check to catch mapping requests exceeding the BAR sizes
    softlockup: Documentation/sysctl/kernel.txt: fix softlockup_thresh description
    dmi scan: warn about too early calls to dmi_check_system()
    generic: redefine resource_size_t as phys_addr_t
    generic: make PFN_PHYS explicitly return phys_addr_t
    generic: add phys_addr_t for holding physical addresses
    softirq: allocate less vectors
    IO resources: fix/remove printk
    printk: robustify printk, update comment
    printk: robustify printk, fix #2
    printk: robustify printk, fix
    printk: robustify printk

    Fixed up conflicts in:
    arch/powerpc/include/asm/types.h
    arch/powerpc/platforms/Kconfig.cputype
    manually.

    Linus Torvalds
     
  • Add documentation in kerneldoc for new printk format extensions

    This patch documents the new %pS/%pF options in printk in kernel doc.

    Hope I didn't miss any other extension.

    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • People can use the real name an an index into MAINTAINERS to find the
    current email address.

    Signed-off-by: Francois Cami
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Francois Cami
     

15 Oct, 2008

1 commit


14 Oct, 2008

1 commit


20 Aug, 2008

2 commits

  • Remove the comment describing the possibility of printk() deadlocking on
    runqueue lock.

    Signed-off-by: Jiri Kosina
    Acked-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar

    Jiri Kosina
     
  • 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 b845b517b5e3706a3729f6ea83b88ab85f0725b0
    > Author: Peter Zijlstra
    > 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] [] debug_smp_processor_id+0xe8/0xf0
    > [ 7697.942005] [] wake_up_klogd+0x1b/0x50
    > [ 7697.942005] [] release_console_sem+0x1e7/0x200
    > [ 7697.942005] [] do_con_write+0xb7/0x1f30
    > [ 7697.942005] [] ? show_trace+0x10/0x20
    > [ 7697.942005] [] ? dump_stack+0x72/0x80
    > [ 7697.942005] [] ? __ratelimit+0xbd/0xe0
    > [ 7697.942005] [] ? debug_smp_processor_id+0xe8/0xf0
    > [ 7697.942005] [] ? wake_up_klogd+0x1b/0x50
    > [ 7697.942005] [] ? release_console_sem+0x1e7/0x200
    > [ 7697.942005] [] con_write+0x19/0x30
    > [ 7697.942005] [] write_chan+0x276/0x3c0
    > [ 7697.942005] [] ? default_wake_function+0x0/0x10
    > [ 7697.942005] [] ? _spin_lock_irqsave+0x22/0x50
    > [ 7697.942005] [] tty_write+0x194/0x260
    > [ 7697.942005] [] ? write_chan+0x0/0x3c0
    > [ 7697.942005] [] redirected_tty_write+0xa4/0xb0
    > [ 7697.942005] [] ? redirected_tty_write+0x0/0xb0
    > [ 7697.942005] [] do_loop_readv_writev+0x52/0x80
    > [ 7697.942005] [] do_readv_writev+0x1bd/0x1d0
    > [ 7697.942005] [] vfs_writev+0x39/0x60
    > [ 7697.942005] [] sys_writev+0x50/0x90
    > [ 7697.942005] [] system_call_fastpath+0x16/0x1b

    Signed-off-by: Peter Zijlstra
    Reported-by: Dmitry Adamushko
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

11 Aug, 2008

1 commit


31 Jul, 2008

1 commit


26 Jul, 2008

1 commit

  • 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: Dave Young
    Cc: "David S. Miller"
    Cc: "Paul E. McKenney"
    Cc: Dave Young
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Young
     

25 Jul, 2008

1 commit


15 Jul, 2008

1 commit


14 Jul, 2008

1 commit


12 Jul, 2008

1 commit


10 Jul, 2008

1 commit


09 Jul, 2008

1 commit


08 Jul, 2008

1 commit


18 Jun, 2008

1 commit

  • It's not explicitly marked as asmlinkage, but invoked from x86_32
    startup code with parameters on stack.

    No other architectures define early_printk and none of them are affected
    by this change, since defines asmlinkage as empty token.

    Signed-off-by: Jiri Slaby
    Cc: H. Peter Anvin
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Jiri Slaby
     

16 Jun, 2008

1 commit


27 May, 2008

1 commit

  • 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 b8c2d3dfbc117dff26058fbac316b8acfc2cb5f7
    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: Markus Armbruster
    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Thomas Gleixner

    Markus Armbruster
     

25 May, 2008

2 commits

  • printk(KERN_ALERT "Danger Will Robinson!\nAlien Approaching!\n");

    At present this will result in one message at ALERT level and one
    at the current default message loglevel (e.g. WARNING). This is
    non-intuitive.

    Modify vprintk() to remember the message loglevel each time it
    is specified and use it for subsequent lines of output which do
    not specify one, within the same call to printk.

    Signed-off-by: Nick Andrew
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Nick Andrew
     
  • Restructure the logic of vprintk() so the processing of the leading
    3 characters of each input line is in one place, regardless whether
    printk_time is enabled. This makes the code smaller and easier to
    understand.

    size reduction in kernel/printk.o:

    text data bss dec hex filename
    6157 397 1049804 1056358 101e66 printk.o.before
    6117 397 1049804 1056318 101e3e printk.o.after

    and some style uncleanlinesses removed as well as a side-effect:

    Before:
    total: 19 errors, 22 warnings, 1340 lines checked
    After:
    total: 17 errors, 22 warnings, 1333 lines checked

    Signed-off-by: Nick Andrew
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Nick Andrew