写了个platform架构的UART测试驱动，在卸载的时候出了问题,驱动卸载不掉，感觉很奇怪，
用户空间使用的rmmod最终会调用kernel/module.c 中的 SYSCALL_DEFINE2(delete_module, const char __user*, name_user, unsigned int, flags)
1、按找lsmod显示的模块名查找模块
mod = find_module(name);
if (!mod) {
ret = -ENOENT;
printk("lccdandeion we cant find mod\n");
goto out;}
2、检查是否有模块依赖于本模块
if (!list_empty(&mod->modules_which_use_me)) {
/* Other modules depend on us: get rid of them first. */
printk("lccdandeion there are modules using me\n");
ret = -EWOULDBLOCK;
goto out;
}
3、检查模块是否存活
/* If it has an init func, it must have an exit func to unload */
if (mod->init && !mod->exit)
{
forced = try_force_unload(flags);
if (!forced) {
/* This module can't be removed */
ret = -EBUSY;
goto out;
}
}
4、若用户空间传递的参数要求强制卸载则卸载（内核编译时要选中可强制卸载模块），检查模块的引用计数是否为零（不为零，则一直等待到引用计数为零）
/* Never wait if forced. */
if (!forced && module_refcount(mod) != 0)
{
printk("lccdandlion wait for zero refcount\n");
wait_for_zero_refcount(mod);
printk("lccdandelion wait end\n");
}
5、
/* Final destruction now noone is using it. */
if (mod->exit != NULL)
{
printk("lccdandeion did we blocked\n");
mod->exit();
}
写的UART驱动测试在调用mod->exit()崩溃。
面对panic，我们该如何定位问题
1、Google
2、利用panic信息、反汇编内核
对于2：
源码树顶层下的Makefile 中KBUILD_CFLAGS ：= -Wall -Wundef -Wstrict-prototype ....
添加 KBUILD_CFLAGS := -g -Wall -Wunde -Wstrict-prototype
这样生成的内核将含有调试信息，611内核源码不支持gdb，但是我们可以反汇编，
unicore32-linux-objdump -Dz -S vmlinux >> linux.dump
根据panic信息可以定位到最终报错时的几个函数调用路径，在函数中打桩，一步步的定位问题，虽然611有些封闭，但是内核核心出现的问题google一般都可以查到。
虽然问题解决了，但是panic的信息还是怪怪的，panic时，pc值竟然不再内核空间中？？？？！！！！