Digilent Embedded Linux - Manual (Page 18)

Using Zynq with Linux
www.digilentinc.com page 18 of 23
Copyright Digilent, Inc. All rights reserved. Other product and company names mentioned may be trademarks of their respective owners.
There are more options in the Kernel Hacking menu that you may choose to enable according to your
needs.
Debug by Printing
Printing is always an easy and useful way to debug code. The kernel provides the printk function,
which works like printf in traditional C libraries. (See Example 18)
Example 18.
printk can work at 8 log levels defined in include/linux/printk.h and listed in Table 2.
Log Level Name Meaning
0 KERN_EMERG when system is unusable, usually before a kernel crash
1 KERN_ALERT when action must be taken immediately
2 KERN_CRIT
in critical conditions, often related to critical software or
hardware failures
3 KERN_ERR
in error conditions, often used in device drivers to report errors
during startup.
4 KERN_WARNING in warning conditions
5 KERN_NOTICE in normal but significant conditions
6 KERN_INFO
to print informational messages, often used by device drivers
to report information during startup.
7 KERN_DEBUG to print debug-level messages
Table 2. Log Level Definitions
By default, any message other than KERN_DEBUG will be printed to console during booting. However,
printk writes all the messages into a ring buffer with length of __LOG_BUF_LEN. You can configure
the size with CONFIG_LOG_BUF_SHIFT under General setup in the kernel configuration menu.
You can also print all of the messages by running a dmesg command in the shell.
Kernel Panic and Oops Messages
When errors occur, the kernel reports either a Panic or an Oops Message on the terminal. When the
kernel panics, the error is fatal and kernel will not recover from it. However, an Oops message will
prompt the kernel to stop any offending processes and keep working. Even if the kernel still appears
to be working correctly, it may have already caused some side-effects that could lead to future kernel
panics.
When the kernel detects a fatal error that it cannot recover from it will call a panic() function. The
panic() function displays a message telling users why the panic occurred. After displaying the
panic message the kernel then stops every CPU and dumps the stack of CPUs if
CONFIG_DEBUG_BUGVERBOSE is selected. The panic message in example 19 shows that the root file
printk(KERN_DEBUG “Here I am: %s:%d\n”, __FUNCTION__, __LINE__);