From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Sun 15 Dec 2002 - 01:18:12 GMT
On Sat, Dec 14, 2002 at 06:42:18PM -0600, Justin M Kuntz wrote:
> Hello,
> We have a few machines running vserver enabled kernels, and while this
> problem is certainly not directly related to vserver, I think we are
> getting a trap on the consoles which may be related to vserver or the
> linux kernel in general - and needs to be debugged/reported. We're
> running 2.4.19-ctx13. Unfortunately, a lot of times when the kernel
> hangs we aren't seeing anything on the screen after we notice the
> hang, because we're running Red Hat 7.3 in runlevel 3, and by default
> the console will get blanked if no keyboard activity is present for a
> while.
hmm, sounds like the vserver/kernel crash is back
with RedHat 7.3 (2.4.19-ctx13) ...
I upgraded all my machines to at least 2.4.20 pre 6,
and had no panics/issues at all (uptime ~ 75 days
on 4 machines) but your milage may vary ...
> Apparently console.c does this automatically unless modified.
> We've found some commands and made a script which should be runnable
> from an SSH session (not necessarily just on the console):
> setterm -term linux -blank 0 > /dev/tty0
> setterm -term linux -powerdown 0 > /dev/tty0
> setterm -term linux -powersave off > /dev/tty0
> (apparently BIOS settings are ignored for these things -- also
> whatever user executing the above must be a member of the "tty" group
> in /etc/group if not root)
> My question is - what are the rest of the vserver users doing to make
> sure that kernel trap messages are not getting lost by these console
> blanking problems?
if you want to do serious bug hunting with the
kernel, you'll probably need a serial line to
the machine and the kernel debugger ...
> Is there some obvious Red Hat option that is
> easier than placing a startup script everywhere, that for some reason
> everyone else has enabled by default that I just didn't know about?
> If so, I'd like to know what it is. :)
serial console can be enabled for lilo/grub and
the linux kernel, you get _ALL_ the boot messages
and it never blanks *G*
> If not, I suggest the rest of us on the list add the above 3 lines to
> some startup script, and then we might have an easier time reporting
> when there are kernel traps (whether they are general kernel issues or
> related to the vserver patch).
best,
Herbert
> Thanks!
> Justin