All of lore.kernel.org
 help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: Tilman Schmidt <tilman@imap.cc>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [2.6.18-rc7] printk output delay in syslog wrt dmesg still unfixed
Date: Tue, 19 Sep 2006 11:52:12 -0700	[thread overview]
Message-ID: <1158691933.18546.3.camel@localhost> (raw)
In-Reply-To: <450BF1CC.2070309@imap.cc>

On Sat, 2006-09-16 at 14:45 +0200, Tilman Schmidt wrote:
> The following problem, which I reported for kernel 2.6.18-rc1 on my
> development machine
>   Dell OptiPlex GX110
>   uname -a = Linux gx110 2.6.18-rc7-noinitrd #1 PREEMPT Thu Sep 14
> 15:13:38 CEST 2006 i686 i686 i386 GNU/Linux
>   933 MHz Pentium III processor, i810 chipset, 512 MB RAM
>   distribution SuSE 10.0, syslog-ng 1.6.8, klogd 1.4.1, Xorg X11 6.8.2
> still exists with 2.6.18-rc7:
> 
> While X is running, output from printk() appears in syslog (eg.
> /var/log/messages) only after a key is pressed on the system keyboard,
> even though it is visible with dmesg immediately.
> 
> Additional observations:
> - The problem is *not* present with 2.6.17.* or earlier kernels.
> - The problem *is* present with 2.6.18-rc*-mm* kernels.
> - The problem disappears if the X server is terminated (telinit 3) and
>   reappears if the X server is started again (telinit 5).
> - Syslog messages from userspace programs are not affected by the delay.
> - No messages are lost, all appear eventually, though possibly hours
>   or days later, depending on how long nobody touches the keyboard.
> - It doesn't matter which key is pressed; even pressing a shift key all
>   by its own is sufficient to make the missing messages appear.
> - I couldn't find any other action that would release the messages;
>   neither mouse movements or clicks, nor waiting up to 24 hours, not
>   even logging in via ssh from another machine and compiling a Linux
>   kernel. ;-)
> - The effect can be clearly observed by the difference between the
>   kernel's own timestamps and those by syslogd; an extreme example:
> 
> Sep 16 14:11:16 gx110 kernel: [18729.057746] gigaset: unblocking all
> channels
> Sep 16 14:11:16 gx110 kernel: [18729.057765] gigaset: searching
> scheduled commands
> Sep 16 14:11:16 gx110 kernel: [86033.298803] gigaset: received response
> (8 bytes): ^M^JZLOG^M^J
> Sep 16 14:11:16 gx110 kernel: [86033.298898] bas_gigaset: cmd_loop: End
> of Command (0 Bytes)
> 
> Please let me know if I can help in any way with locating the cause of
> this annoying phenomenon.

Unfortunately I don't know what would be the cause. 

You might try git-bisect to find the offending patch.
http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt


thanks
-john


  reply	other threads:[~2006-09-19 18:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-16 12:45 [2.6.18-rc7] printk output delay in syslog wrt dmesg still unfixed Tilman Schmidt
2006-09-19 18:52 ` john stultz [this message]
2006-09-20 10:01   ` Tilman Schmidt
2006-09-21 23:28   ` Tilman Schmidt
2006-09-21 23:35     ` john stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1158691933.18546.3.camel@localhost \
    --to=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tilman@imap.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.