debuggingbyprinting

1、debuggingbyprintingProbably the simplest way to get some debug informationfrom your kernel code is by printing out various information with the kernel's equivalent of printf - the printk function and its derivatives.The k in printk is used to specifically remind kernel developers that the enviro

2、nment is different.Contents hide1 Usage2 Log Levels3 Rate limiting and one time messages4 Printk from userspace5 Internals / Changing the size of the printk buffer6 Pros and Cons7 Debugging early boot problems7.1 Accessing the printk buffer after a silent hang on boot7.1.1 Redboot example on a Frees

3、cale ADS board7.1.2 U-boot example on an OMAP OSK board7.1.3 Grub7.2 Using CONFIG_DEBUG_LL and printascii() (ARM only)8 NetConsole8.1 Netconsole resources9 Misc9.1 Dmesg / Clearing the buffer 9.2 Printk Timestamps9.3 Printing buffers as hex9.4 Dynamic Debugging10 Disabling printk messages at compile

4、 time11 References and external linksUsage printk works more or less the same way as printf in userspace, so if you ever debugged your userspace program using printf, you are ready to do the same with your kernel code, e.g. by adding: printk("My Debugger is Printkn");This wasn't that d

5、ifficult, was it?Usually you would print out some more interesting information like printk("Var1 %d var2 %dn", var1, var2);just like in userspace.In order to see the kernel messages, just use the$ dmesg command in one of your shells - this one will print out thewhole kernel log buffer to y

6、ou.Most of the conversion specifiers supported by the user-space library routine printf() are also available in the kernel;there are some notable additions, including "%pf", which will print the symbol name in place of the numeric pointer value, if available.The supported format strings ar

7、e quite extensively documented inDocumentation/printk-formats.txtHowever please note: always use %zu, %zd or %zx for printing size_t and ssize_t values. ssize_t and size_t are quite common values in the kernel, so please use the %z to avoid annoying compile warnings.Author's practical advice:If

8、you want to debug an oops (e.g caused by releasing a resource twice) in your driver and you don't have a clue where the oops happens, simply add this line printk(KERN_ALERT "DEBUG: Passed %s %d n",_FUNCTION_,_LINE_);after each possibly offending statement.Recompile and (re-)load the mo

9、dule and trigger the error condition - your log now shows you the last line that was successfully executed before the oops happened.Of course you should remove these 'rude' statements before shipping your module ;)Log LevelsIf you look into real kernel code you will always see something like

10、: printk(KERN_ERR "something went wrong, return code: %dn",ret);where "KERN_ERR" is one of the eight different log levels defined in include/linux/kern_levels.h and specifies the severity of the error message.Note that there is NO comma between the KERN_ERR and the format string

11、(as the preprocessor concatenates both strings)The log levels are:NameStringMeaning alias functionKERN_EMERG"0"Emergency messages, system is about to crash or is unstable pr_emergKERN_ALERT"1"Something bad happened and action must be taken immediately pr_alertKERN_CRIT"2&quo

12、t;A critical condition occurred like a serious hardware/software failure pr_critKERN_ERR"3"An error condition, often used by drivers to indicate difficulties with the hardware pr_errKERN_WARNING"4"A warning, meaning nothing serious by itself but might indicate problems pr_warningKERN_NOTICE"5"Nothing serious, but notably nevertheless. Often used to report security events.pr_noticeKERN_INFOInformational message e.g. startup information at driver initialization pr_infoKERN_DEBUG"7"Debug messages