There are other (mostly simpler) ways to get some commonly needed error output from the kernel, unmodified, as well. Standard system logs are often useful, and should be consulted first, such as /var/log/messages . If your system is not completely dead, the "dmesg" utility could help (but may only deliver what is in the logs anyway). And you can possibly get the kernel to dump some info through the "magic SysRq keys", even after a kernel panic, if this feature is activated in advance; see /usr/share/doc/kernel-doc-2.4.20/sysrq.txt, or where-ever "locate" shows that file lives in your distribution, for details. To activate it, put the following line in /etc/sysctl.conf: kernel.sysrq = 1 Don't forget to manually activate it the first time (automatic on bootup). And you might be able to get the stock kernels to deliver even more diagnostic info by turning on features related to that using the sysctl utility (consult the man page -- I haven't checked). Mostly, recompiling kernels for various features is out-of-date strategy. Stock kernels now normally have everything a distributor can reasonably bundle with it, and you only have to figure out how to activate those features, such as tuning the kernel or loading modules (often automatic). For exceptions to that, there are web archives where you can get other stuff: for instance, low latency kernels with the advanced alsa sound drivers (for my case), already built in are available, for professional audio work or just better performance and features in your card. Other kernels are out there for pretty much whatever else you need. Also, much info is stored in the /proc (fake) filesystem directories, and can be conveniently accessed through front end utilities like lsdev. And a search at http://www.google.com/linux can be very helpful. And there are yet more resources, such as HOWTOs (see the blinux FAQ). One problem with helping you with a concise answer is that you have been very vague about the actual nature of the problem; otherwise someone here might have been able to tell you exactly where to get the info you need. And a common strategy with vague postings is to ignore them, thus protecting one from info overload (and related hassles and drains) on the net (I do it all the time). LCR On Tue, 27 Jan 2004, Andor Demarteau wrote: > On Mon, 26 Jan 2004, [iso-8859-15] Sébastien FRANÇOIS wrote: > > > I have a friend who is trying to help me > > > debug a kernel problem. I am wondering if > > > there is any way to log the problems that > > > the kernel encounters when you load it and > > > it blows up. He needs this to help me > > > debug what is wrong. Thanks for the help. > > There is a way to request the kernel to send > > info over a serial line, I have never done > > this though > it's an option in the kernel itself caleld > "output to serial dump terminal" it effectively > gives all kernel-output over the serial-poort. A > bootoption controls which port is used. You can > also login via the serial terminal, but you have > to uncomment the correct line in /etc/inittab as > well to make this possible. -- L. C. Robinson reply to no_spam+munged_lcr@xxxxxxxxxxxxxxxxxxx People buy MicroShaft for compatibility, but get incompatibility and instability instead. This is award winning "innovation". Find out how MS holds your data hostage with "The *Lens*"; see "CyberSnare" at http://www.netaction.org/msoft/cybersnare.html _______________________________________________ Blinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-list