All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tilman Schmidt <tilman@imap.cc>
To: linux-kernel@vger.kernel.org
Cc: john stultz <johnstul@us.ibm.com>
Subject: [2.6.18-rc7] printk output delay in syslog wrt dmesg still unfixed
Date: Sat, 16 Sep 2006 14:45:00 +0200	[thread overview]
Message-ID: <450BF1CC.2070309@imap.cc> (raw)

[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]

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.

Thanks
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeoeffnet mindestens haltbar bis: (siehe Rueckseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

             reply	other threads:[~2006-09-16 12:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-16 12:45 Tilman Schmidt [this message]
2006-09-19 18:52 ` [2.6.18-rc7] printk output delay in syslog wrt dmesg still unfixed john stultz
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=450BF1CC.2070309@imap.cc \
    --to=tilman@imap.cc \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.