码迷,mamicode.com
首页 > 系统相关 > 详细

Linux设备驱动故障定位指引与实例

时间:2017-09-15 01:55:27      阅读:524      评论:0      收藏:0      [点我收藏+]

标签:targe   har   进程   修改   nobody   pre   val   补丁   结果   

Linux设备驱动故障定位指引

Linux设备驱动种类繁多,涉及的知识点多,想写一个通用的故障定位方法指引,是个难度颇大且不容易做好的工作。限于笔者的经验,难以避免存在疏漏之处,欢迎大家留言指正补充。

Linux设备驱动的知识点涉及硬件和软件,故障原因也各种各样,不过从笔者多年的维护经验来看,硬件相关问题导致的设备驱动故障还是占了较大的比例,而大部分的硬件问题特别是环境问题也是相对来说较容易排查的。下图是Linux设备驱动故障定位脑图(大图),图中按硬件和软件分为两类,硬件分类又细分为环境、芯片和上级总线/桥片,软件分类又细分为bootloader和内核驱动。每个检查点给出检查项和检查方法。

技术分享

 

MTD设备驱动故障定位示例

故障描述

某一块单板上有一块型号S29GL01GT11TFIV10的NOR flash,其上使用UBIFS文件系统,用于储存3.10内核镜像。测试中发现单板上电过程中,大概有10%的概率会偶现如下内核异常,并且此后所有flash命令操作都失败,flash无法正常访问:

MTD get_chip(): chip not ready after erase suspend
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 932:36992, written 0 bytes
notice(4295011711): cpu0 max interrupt interval is 112812200ns
sCall Trace: [jiffies: 0x10000ad9b]
[<ffffffffc0be76cc>] dump_stack+0x8/0x34
[<ffffffffc0a0b624>] ubi_io_write+0x52c/0x670
[<ffffffffc0a079e8>] ubi_eba_write_leb+0xd8/0x758
[<ffffffffc0897470>] ubifs_leb_write+0xd0/0x178
[<ffffffffc0898cd0>] ubifs_wbuf_write_nolock+0x430/0x798
[<ffffffffc088b16c>] ubifs_jnl_write_data+0x1e4/0x348
[<ffffffffc088e5a8>] do_writepage+0xc8/0x258
[<ffffffffc0714d70>] __writepage+0x18/0x78
[<ffffffffc0715ab8>] write_cache_pages+0x1e0/0x4c8
[<ffffffffc0715de0>] generic_writepages+0x40/0x78
[<ffffffffc0784620>] __writeback_single_inode+0x58/0x370
[<ffffffffc0785b84>] writeback_sb_inodes+0x2e4/0x498
[<ffffffffc0785df8>] __writeback_inodes_wb+0xc0/0x118
[<ffffffffc07862fc>] wb_writeback+0x234/0x3c0
[<ffffffffc0786918>] wb_do_writeback+0x230/0x2b0
[<ffffffffc0786a1c>] bdi_writeback_workfn+0x84/0x268
[<ffffffffc0670300>] process_one_work+0x180/0x4d0
[<ffffffffc0671848>] worker_thread+0x158/0x420
[<ffffffffc06786c0>] kthread+0xa8/0xb0
[<ffffffffc06204c8>] ret_from_kernel_thread+0x10/0x18

 

故障分析及定位步骤

相应代码片段如下(所在位置:drivers/mtd/chips/cfi_cmdset_0002.c:get_chip),其实现功能是如果发现当前flash处在擦除状态,下发erase suspend(CMD(0xB0))命令,暂停块擦除操作,使flash处理就绪状态。

之所以需要有erase suspend,是因为UBI有后台进程ubi_bgt0d,此进程功能是对flash块进行垃圾回收、磨损均衡、torture check等,当用户访问flash时,为了立即响应用户,需要立即暂停后台进程的操作,避免因为后台进程长时间占用flash而导致用户请求得不到及时响应的情况。

下发了erase suspend命令后,如果timeo时间内(这里是1s),flash还没有进入就绪状态,则说明flash出现问题,后面所有的flash命令操作都开始失败。flash的就绪检查由chip_ready实现,其实现原理是:同一个地址读两次,如果值相同,则说明flash已就绪。问题出现后,flash出错地址读出的字节的确一直在0x28和0x6c间跳变,无法稳定下来。

	case FL_ERASING:
		if (!cfip || !(cfip->EraseSuspend & (0x1|0x2)) ||
		    !(mode == FL_READY || mode == FL_POINT ||
		    (mode == FL_WRITING && (cfip->EraseSuspend & 0x2))))
			goto sleep;

		/* We could check to see if we‘re trying to access the sector
		 * that is currently being erased. However, no user will try
		 * anything like that so we just wait for the timeout. */

		/* Erase suspend */
		/* It‘s harmless to issue the Erase-Suspend and Erase-Resume
		 * commands when the erase algorithm isn‘t in progress. */
		map_write(map, CMD(0xB0), chip->in_progress_block_addr);
		chip->oldstate = FL_ERASING;
		chip->state = FL_ERASE_SUSPENDING;
		chip->erase_suspended = 1;
		for (;;) {
			if (chip_ready(map, adr))
				break;

			if (time_after(jiffies, timeo)) {
				/* Should have suspended the erase by now.
				 * Send an Erase-Resume command as either
				 * there was an error (so leave the erase
				 * routine to recover from it) or we trying to
				 * use the erase-in-progress sector. */
				put_chip(map, chip, adr);
				printk(KERN_ERR "MTD %s(): chip not ready after erase suspend\n", __func__);
				return -EIO;
			}

			mutex_unlock(&chip->mutex);
			cfi_udelay(1);
			mutex_lock(&chip->mutex);
			/* Nobody will touch it while it‘s in state FL_ERASE_SUSPENDING.
			   So we can just loop here. */
		}
		chip->state = FL_READY;
		return 0;

参照上面的故障定位脑图,排除一些不适用此故障的排查点,我们的故障排查顺序和结果如下:

技术分享

 

修复方案及补丁提交

修改方案也很简单,就是针对S29GL01GT/S29GL512T,在Erase Resume命令下发后,延时500μs。

具体实现可查看此补丁提交链接

--EOF--

  

Linux设备驱动故障定位指引与实例

标签:targe   har   进程   修改   nobody   pre   val   补丁   结果   

原文地址:http://www.cnblogs.com/wahaha02/p/7495502.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!