Console not capturing call trace

Previous thread: [PATCH] cr_bllcd: use platform_device_register_simple() by Akinobu Mita on Sunday, September 21, 2008 - 7:39 am. (1 message)

Next thread: [PATCH 0/2] vgacon_scrolldelta cleanup by Marcin Slusarz on Sunday, September 21, 2008 - 9:00 am. (5 messages)
From: Jay Cliburn
Date: Sunday, September 21, 2008 - 8:46 am

I'm thinking this may be a userspace issue, but most users don't hack
network drivers and don't encounter kernel warnings and oopses, and
therefore aren't likely to encounter this, so I'm bringing it to the
kernel list (especially those who run Fedora) for assistance/opinions.

The problem:  I no longer get full module lists and call traces on the
console for a WARN_ON (for example).  I run Fedora 9 and its current
version of rsyslog-3.18.1-2.fc9.x86_64.  Reverting to
rsyslog-3.14.1-2.fc9.x86_64 or advancing to
rsyslog-3.21.3-3.fc10.x86_64 didn't seem to help.  

For test purposes I inserted a WARN_ON(1) statement in the atl1 driver,
and dmesg shows the output just fine, but /var/log/messages and my
serial console both fail to show the module list and call trace.
(Evidence below.)

One thing I can't figure out is where the "<8>" comes from in
the serial console output down at the bottom of this message.
Backstepping from warn_on_slowpath() to print_modules() in the kernel
code doesn't seem to show an <8> printed anywhere.  I've got 
/proc/sys/kernel/printk set to 8 8 8 8, so maybe that's related?

Has anyone else encountered this or know which rsyslogd knob to tweak
to enable the full modules list and call trace?  I've verified the
condition occurs with current git, 2.6.26.3, and 2.6.25.16 kernels, so I
think it's not a kernel problem.  It *used* to work fine, but I can't 
remember when it stopped doing so.

From dmesg, which is what the output *should* look like.

[ 3487.555651] ------------[ cut here ]------------
[ 3487.569484] WARNING: at drivers/net/atlx/atl1.c:2735 atl1_open+0x40/0x51 [atl1]()
[ 3487.569485] Modules linked in: sit tunnel4 fuse nf_conntrack_ipv4 ipt_REJECT iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand dm_mirror dm_log dm_multipath dm_mod snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event atl2 snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm ...
From: Vegard Nossum
Date: Sunday, September 28, 2008 - 5:14 am

Hi,

I'll try an answer since you've had no other replies.

You probably need to set up rsyslogd to log all kernel messages. For
me, changing the /etc/rsyslog.conf like this does the trick (but
beware of my linewrapping client):

--- rsyslog.conf.orig   2008-09-28 14:10:20.000000000 +0200
+++ rsyslog.conf.new    2008-09-28 14:10:12.000000000 +0200
@@ -36,7 +36,7 @@

 # Log anything (except mail) of level info or higher.
 # Don't log private authentication messages!
-*.info;mail.none;authpriv.none;cron.none                /var/log/messages
+kern.*;*.info;mail.none;authpriv.none;cron.none
/var/log/messages

 # The authpriv file has restricted access.
 authpriv.*                                              /var/log/secure


I.e., you just need to add "kern.*" in the line that controls logging
to /var/log/messages. I hope this helps.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--

From: Jay Cliburn
Date: Sunday, September 28, 2008 - 5:38 am

On Sun, 28 Sep 2008 14:14:09 +0200

Thanks for replying Vegard.  The problem turned out to be that I
overwrote /proc/sys/kernel/printk with "8 8 8 8" instead of just using
"8 x x x," where x is the default value.
--

Previous thread: [PATCH] cr_bllcd: use platform_device_register_simple() by Akinobu Mita on Sunday, September 21, 2008 - 7:39 am. (1 message)

Next thread: [PATCH 0/2] vgacon_scrolldelta cleanup by Marcin Slusarz on Sunday, September 21, 2008 - 9:00 am. (5 messages)