内核问题解决办法记录
♪文章源自微观生活（93wg.com）微观生活-https://93wg.com/14121.html
张释文 文章源自微观生活（93wg.com）微观生活-https://93wg.com/14121.html
在内核开发这块，基本工作都是：打补钉，调补钉，调bug。最耗神的就是调bug，调bug的进程最花时间的一步是定位问题，基本上只要定位到问题，解决起来就容易些了（目前我遇到的bug大部份是这样）。所以调试办法很重要，接下来就分享一点怎么快速定位并解决bug的一丢丢小经验。抛砖引玉，大佬们见笑。文章源自微观生活（93wg.com）微观生活-https://93wg.com/14121.html
Contents
1 分析文章源自微观生活（93wg.com）微观生活-https://93wg.com/14121.html
1.1 依据函数栈定位问题文章源自微观生活（93wg.com）微观生活-https://93wg.com/14121.html
1.2 依据 modules信息定位问题文章源自微观生活（93wg.com）微观生活-https://93wg.com/14121.html
2 打开对应的debug文章源自微观生活（93wg.com）微观生活-https://93wg.com/14121.html
3 跟进去文章源自微观生活（93wg.com）微观生活-https://93wg.com/14121.html
分析文章源自微观生活（93wg.com）微观生活-https://93wg.com/14121.html
依据函数栈定位问题
内核出了bug，首先做的应当是分析这个很重要。如果分析的好，后面可以节省不少时间。依据内核打出的过错日志分析，分析是哪里出了问题。比如说这样的dmesg：
[226041.366182] BUG: unable to handle kernel pointer dereference at 0000000000000050[226041.366336] IP: [<ffffffff812102f1>] lock_get_status+0xa1/0x340[226041.366492] PGD 2d0d74067 PUD 2d9550067 PMD 0[226041.366649] Oops: 0000 [
依据 modules信息定位问题
以前一直没细心看过dmesg中打出来的模块信息，直到遇到下面这个问题：
[ 1722.892969] CPU 1 Unable to handle kernel paging request at virtual address 0000000049e50b00, epc == ffffffff803914[ 1722.976089] Oops[
打开对应的debug
内核有时候会报RCU过错，就比如下面这类：
[ 52.098924] NMI watchdog: BUG: soft lockup - CPU
CONFIG_DEBUG_KERNEL=yCONFIG_DETECT_SOFTLOCKUP=yCONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0CONFIG_DETECT_HUNG_TASK=yCONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0CONFIG_SCHED_DEBUG=yCONFIG_DEBUG_PREEMPT=yCONFIG_DEBUG_BUGVERBOSE=yCONFIG_DEBUG_INFO=yCONFIG_DEBUG_RCU
在kernel hacking中打开，irq、rcu、lock之类相关的全体开关
运气好的话可以得到更详细的信息，相似于：
[ 40.816000] Badness at drivers/stm/clk.c:190[ 40.816000][ 40.816000] Pid : 779, Co妹妹: reboot[ 40.816000] CPU : 0 Not tainted (2.6.32.59_stm24_0211
跟进去
如果上述办法都不能解决问题，这是最后一个且最麻烦的方法了，跟进去调试。一点一点，要无比有耐心，渐渐分析流程，斗胆假想可能犯错的位置。秘诀就是：仔细、耐心以及斗胆假想。
比如说以前调的掉盘考题，dmesg打印的信息如下：
[ 4.233517] irq 123, desc: ffff890efa766800, depth: 1, count: 0, unhandled: 0[ 4.233528] ->handle_irq: ffffffffa80e5b60,[ 4.233552] handle_bad_irq+0x0/0x230[ 4.233554] ->irq_data.chip: ffffffffa8f711a0,[ 4.233559] chv_gpio_irqchip+0x0/0x120[ 4.233561] ->action: [ 4.233563] IRQ_NOPROBE set[ 6.547628] ata2.00: qc timeout (cmd 0xec)[ 6.547721] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)[ 7.007213] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)[ 16.997819] ata2.00: qc timeout (cmd 0xec)[ 16.997910] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
屡次重启测试后，基本上能肯定在123号中止呈现之后，盘就掉了。系统hang住。怀疑是ata驱动的问题。bad irq问题是最难肯定的一种问题，由于中止是硬件发生的，没方法看到
发生的进程，所以只能笨拙的一点一点扣代码，一点点猜，这需要耐心。大概猜了200+次之后，才能基本肯定跟ata驱动没关系（由于可能之处都查看过了，没问题）。
问题是由异样中止引发的，既然不是驱动的问题，那就是中止处理的问题咯。这是一个斗胆的料想，由于所有的中止工作都是ok的，只是这一个。后面调试还真是中止处理流的问题。orz….其实只要仔细一点。应当不用尝试200+次后，定位出来的。
这就是我分享的这个季度用到的定位办法，比较粗拙。各位大神们还有什么好用的方法，请教。
以上就是微观生活（93wg.com）关于“内核问题解决办法记录”的详细内容，希望对大家有所帮助！
评论