All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Pavel Ivanov <paivanof@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] Allow for stack traces to be printed on serial console
Date: Mon, 03 Oct 2011 15:00:14 +0530	[thread overview]
Message-ID: <4E8980A6.8000905@linux.vnet.ibm.com> (raw)
In-Reply-To: <1317358146.9597.11.camel@PavelComp>

On 09/30/2011 10:19 AM, Pavel Ivanov wrote:
> When I tried to chase some mysterious lockup of my PC the only means to
> see some error reports for me was serial console. But it looks like only
> printk with KERN_ERR is sent to serial console. So when hung task
> detector tried to show me stack traces for hung tasks I didn't see them
> on serial console and I didn't see them after reboot as they couldn't be
> saved to dmesg. Thus the following patch allowed me to actually see
> those stack traces.

Which kernel messages gets displayed on your serial console is controlled by
your system configuration which can be altered by modifying /etc/rsyslog.conf
or /etc/sysconfig/syslog.conf 
There you can specify that you want to print every kernel message by specifying
kern.* for example.

There are also some kernel command line options you can use to specify which 
level of kernel messages you want to get displayed.

Since you clearly have a system configuration problem here, you don't need to alter the
kernel source to print with KERN_ERR everywhere. Doing that would also defeat the very
purpose of having that nice distinction between informational messages, error messages
and so on, isn't it?

> I believe kernel prints stack traces only in some serious cases and
> expects that they would be actually seen, so KERN_ERR looks justified
> for me in all changed places. I understand that patch is incomplete and
> would need some other places to be changed for consistency (at least
> other arch code). But first I want to hear comments on whether this
> approach is good enough to be included in mainline or it should be left
> for me as a hack.
> 
-- 
Regards,
Srivatsa S. Bhat  <srivatsa.bhat@linux.vnet.ibm.com>
Linux Technology Center,
IBM India Systems and Technology Lab

  reply	other threads:[~2011-10-03  9:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAG1a4rtrh7=+gr=kUGO6y4wt926F8rBusOcFgvu4CmvrmR5PCw@mail.gmail.com>
2011-09-30  4:49 ` [RFC PATCH] Allow for stack traces to be printed on serial console Pavel Ivanov
2011-10-03  9:30   ` Srivatsa S. Bhat [this message]
2011-10-05 22:03     ` Pavel Ivanov

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=4E8980A6.8000905@linux.vnet.ibm.com \
    --to=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paivanof@gmail.com \
    /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.