Difference between revisions of "Kernel Debugging Tips"

From eLinux.org
Jump to: navigation, search
(Accessing the printk buffer after a silent hang on boot: add bold to tip)
Line 25: Line 25:
  
 
And you see the printk buffer that never got flushed
 
And you see the printk buffer that never got flushed
to the UART.  Knowing what's there can be _very_
+
to the UART.  Knowing what's there can be '''very'''
 
useful in debugging your console.
 
useful in debugging your console.
  
 
[[Category:Development Tools]]
 
[[Category:Development Tools]]

Revision as of 21:20, 12 February 2008

Here are some miscellaneous tips for debugging a kernel:

Accessing the printk buffer after a silent hang on boot

Quinn Jensen writes:

Something I've found handy when the console is silent is to dump the printk buffer from the boot loader. To do it you have to know how your boot loader maps memory compared to the kernel. Here's what I do with Redboot on i.MX31:

fgrep printk_buf System.map

this shows the linked address of the printk_buf, e.g.:

c02338f0 b printk_buf.16194

The address "c02338f0" is in kernel virtual, which, in the case of i.MX31 ADS, redboot will have mapped to 0x802338f0. So, after resetting the target board, but without letting it try to boot again, at the redboot prompt,

dump -b 0x802338f0 -l 10000

And you see the printk buffer that never got flushed to the UART. Knowing what's there can be very useful in debugging your console.