In some debug scenerios it can be helpful to debug the kernel running inside a virtual machine. Boot with this option, chvt 1 (to console #1), and suspend using pm-suspend This will force the console not to suspend. One can stop console messages from being suspended by using the kernel parameter no_console_suspend: Where N = msecs delay between each console message.ĭebugging suspend/resume issues can be difficult if the kernel panics during suspend, especially late in the suspend because console messages are disabled. One can slow down kernel console messages at boot time using by building the kernel with the following option enabled:Īnd boot the machine with the following kernel boot parameter: One may find a machine hangs during the kernel boot process and one would like to be able to see all the kernel messages but unfortunately they scroll off the console too quickly. To do this, modify dump_stack in arch/x86/kernel/dumpstack_*.c and comment out the call to show_trace() Of course, one may still have a stack dump that scrolls the top of the Oops message off the console, so one trick is to rebuild the kernel with the stack dump removed, just to capture the initial Oops information. Hence to capture more of a Oops, try the following: Unfortunately the stack dump can be more than 25 lines and can scroll off the top of the 25 line Virtual Console. Kernel Oops messages general contain a fair amount of information, ranging from register and process state dump and a stack dump too. Note: Generally, there is NO hardware or software flow control on serial console drivers, which means one may get dropped characters when running very high speed tty baud rates, such as 115200 baud. One may need to adjust the baud rate appropriately. In addition, one needs to enable USB serial support as a kernel build configuration: Most commonly this will be a DB9 female to DB9 female null serial cable. A "null serial cable" or "universal file transfer cable" is needed to connect the target computer with the host. Most modern PCs do not have legacy serial ports, so instead, one can use a USB serial dongle instead. Serial console enables one to dump out console messages over a serial cable. This will disable the usplash splash screen and re-enable console messages. To view console messages at boot, remove the quite and splash boot parameters from the kernel boot line in grub. For example, enable all levels of console message: If one does not specify the log level then the default log level of KERN_WARNING is used. printk(KERN_DEBUG "example debug message\n") KERN_NOTICE /* normal but significant condition */Į.g. KERN_ALERT /* action must be taken immediately */ One can specify the type of printk() log level by pre-pending the 1st printk() argument with one of the following: Where N is the size of the buffer in bytes, and must be a power of 2. To increase the internal buffer, use the kernel boot parameter: If the buffer fills up, it wraps around and one can lose valueable debug messages. The internal kernel console message buffer can sometimes be too small to capture all of the printk messages, especially when debug code generates a lot of printk messages. Note that printk() can slow down the execution of code which can alter the way code runs, for example, changing the way race conditions occur. This enables one to print messages to the console, and it very similar to printf(). The simplest, and probably most effective way to debug the kernel is via printk(). This page describes some tricks and techniques to help debug the kernel. Using GDB to find the location where your kernel panicked or oopsed.ĭebugging the kernel is not necessarily rocket science in fact it can be achieved using very simple and straight forward techniques and some time, patience and perseverance.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |