[lkml]   [2005]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: printk loglevel policy?
    Jim Nelson wrote:
    > Alan Cox wrote:
    >> On Gwe, 2004-12-31 at 02:20, Coywolf Qi Hunt wrote:
    >>> Hi all,
    >>> Recently, I've seen a lot of add loglevel to printk patches. grep
    >>> 'printk("' -r | wc shows me 2433. There are probably 2433 printk
    >>> need to patch, is it? What's this printk loglevel policy, all these
    >> You would need to work out which were at the start of a newline - most
    >> of them are probably just fine and valid
    > That reminds me of a question I've had inthe back of my head. When you
    > have a SMP system wouldn't it be possible to have:
    > CPU 1 (running func1) CPU 2 (running func2)
    > | |
    > printk ("foo..."); |
    > | printk ("bleh\n");
    > printk ("finished\n); |
    > printk ("readout from bleh\n";
    > Is that possible? Especially if the process on CPU 1 slept on a
    > semaphore or something similar?
    > Or does printk() do some tracking that I didn't see as to where in the
    > kernel the strings are coming from?

    That kind of garbled output has been known to happen, but
    the <console_sem> is supposed to prevent that (along with
    zap_locks() in kernel/printk.c).

    If it still happens, it needs to be fixed.
    David Howells (RH) has posted patches that fix it.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.022 / U:2.196 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site