lkml.org 
[lkml]   [2001]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.14-pre8 Alt-SysRq-[TM] failure during lockup...
"Eric W. Biederman" wrote:
>
> "Randy.Dunlap" <rddunlap@osdl.org> writes:
>
> > "Eric W. Biederman" wrote:
> > >
> > > Summary: I triggered a condition in 2.4.14-pre8 where SysRq triggered
> > > but would not print reports. I managed to unstick the condition but
> > > had played to much to determine the root cause. My guess is that
> > > somehow my default loglevel was messed up. Full information is
> > > provided just case I did not muddy the waters too much.
> >
> > Do you know what the console loglevel was when you tried
> > to use Alt-SysRq-M (show_mem) or Alt-SysRq-T (show tasks ==
> > show_state)? (first value listed in /proc/sys/kernel/printk file)
>
> I was in single user mode so it shouldn't have been changed
> from it's default value. But it might have been.

Eric,

I have seen some distro(s) in which either syslogd or klogd (I'm
guessing) uses the syslog syscall to change the console loglevel
value in the kernel.
This could still happen in single user mode, couldn't it?

It bugged me because I often use the "debug" boot parameter
to set console_loglevel to 10, but all of a sudden it had been
set back to 6 IIRC! And right now on one of my test
systems it is set to 0 according to /proc/sys/kernel/printk,
although _I_ didn't ask for it to be changed to 0, and
I haven't been able to find what's changing it to 0, since
it was 10 during init/main.c.

~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:12    [W:0.112 / U:0.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site