kernel启动控制台还不可用时发生crash的调试方法

 

kernel启动控制台还不可用时发生crash的调试方法

在调试linux kernel时，如果crash发生在控制台还不可用时，那将没有任何信息能够被打印，那分析原因就变成了一摸黑。有以下方法有助于帮助分析：

1, early printk

在kernel配置选项中启用CONFIG_EARLY_PRINTK=y, 那将可借助early_printk()函数打印信息，用early_printk在kernel启动的代码中加入一些打印点，可以帮助定位kernel boot到哪一位置。

early_printk的配置选项位于Kernel hacking, 还必须开启了CONFIG_DEBUG_LL=y，才能启用early printk.

Kernel hacking ----> 
    [*] Kernel low-level debugging functions 
    [*]     Early printk

这一功能，需要你的arch实现底层的uart发送函数， 即include/mach/debug-macro.S中的addruart, senduart, waituart, busyuart等函数。

2, dump log_buf内存

printk函数打印的信息首先都是存在log_buf这块内存的，即使console还没enable，printk函数也一样可以被调用，因此当kernel crash时，可以通过仿真器查看log_buf 这段内存，它里面存的就是通过printk打印的信息，如果没有仿真器，也可以重启bootloader，在bootloader里通过dump mem来查看。

log_buf这段内存的地址如何确定？通过System.map文件搜索log_buf，你就会找到log_buf的地址,如：

c0535bd8 b printk_buf 
c0535fd8 b printk_time 
c0535fdc b __log_buf 
c0539fdc b cpu_online_bits 
c0539fe0 b cpu_active_bits 
c0539fe4 b cpu_present_bits 
c0539fe8 b cpu_possible_bits 
c0539fec B sys_tz 
c053a000 b softirq_vec

这里我们看到log_buf的内存地址在c0535fdc，这是个虚拟地址，根据kernel地址映射规律，从MEM_PHY_START到MEM_PHY_END，都会一一映射到0xc0000000: (0xc0000000 + MEM_PHY_SIZE)，因此假设我们内存的物理地址起始是0x0，那么这里log_buf的实际物理地址为0x00535fdc。

在确认完log_buf的内存地址之后，就可以用仿真器也好，bootloader也好，去查看printk打印的内容了。

 

地址

 http://code.google.com/p/innosoc/wiki/KernelBootCrashDebug