写了个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值竟然不再内核空间中？？？？！！！！