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
