优先用modprobe而非insmod，因modprobe自动解析依赖、搜索标准路径、支持配置文件；卸载必须用modprobe -r，它能递归卸载依赖模块，而rmmod仅单点移除易报“module is in use”。
优先用 modprobe，别直接上 insmod；卸载必须用 modprobe -r，rmmod 很容易卡死。
加载驱动：用 modprobe 还是 insmod？
绝大多数情况下，你应该用 modprobe。它会自动查 /lib/modules/$(uname -r)/modules.dep，递归加载所有依赖模块（比如加载 uas 前，自动先加载 usbcore 和 scsi_mod）；而 insmod 只认绝对路径，不处理依赖、不读配置、不支持别名，硬塞一个 .ko 文件进去，十有八九报 Unknown symbol in module。
- 正确做法：
sudo modprobe igb（不用写.ko，也不用给路径） - 错误做法：
sudo insmod /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/intel/igb/igb.ko—— 除非你确认该模块完全无依赖且已验证过符号兼容 - 如果模块不在标准路径，先运行
sudo depmod -a更新依赖索引，再modprobe - 加载带参数时，
sudo modprobe igb InterruptThrottleRate=3000比insmod ... InterruptThrottleRate=3000更可靠，因为前者能触发/etc/modprobe.d/*.conf中预设的校验逻辑
卸载驱动：为什么 rmmod 总提示 “Module is in use”？
rmmod 是“单点移除”，只看目标模块自己的引用计数（lsmod 输出里的 used by 列）。只要这个数字非零（哪怕只是另一个模块在 module_depends 里声明了它），就拒绝卸载。而 modprobe -r 会反向遍历整个依赖图，先卸载所有依赖它的子模块，再清理目标模块。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 安全卸载：
sudo modprobe -r igb（自动处理上下游依赖） - 危险操作：
sudo rmmod -f igb—— 若模块正处理中断或持有锁，可能引发Kernel panic，生产环境禁用 - 卸载前务必检查：
lsmod | grep ^igb看used by是否为 0；再跑lsof /dev/igb* 2>/dev/null或find /sys -name "*igb*" 2>/dev/null排查隐式占用 - 某些驱动（如
nvidia）会被 X Server、containerd 或 GPU 监控进程锁定，需先停服务：sudo systemctl stop gdm3或sudo pkill -f nvidia-persistenced
加载失败排查：光看 lsmod 没用，得盯 dmesg
lsmod 只告诉你模块“在列表里”，不代表初始化成功。真正可靠的判断依据是内核日志 —— 模块的 init 函数里 printk() 输出、硬件 probe 失败、内存分配错误，全在这里暴露。
- 加载后立刻执行：
dmesg | tail -20，搜igb:、error、fail、unknown - 常见失败原因：
vermagic不匹配（modinfo igb.ko对比uname -r）、固件缺失（dmesg提示firmware: failed to load）、PCI 设备未被扫描到（lspci | grep 8086:1521） - 如果
insmod失败后模块已部分载入，后续modprobe可能卡住，此时先sudo dmesg | tail -20确认状态，再考虑sudo rmmod -f igb强制清理（仅限调试环境） - 模块被
blacklist也会静默失败：modprobe --showconfig | grep igb查是否被屏蔽，或看/etc/modprobe.d/*.conf里有没有blacklist igb
手动加载的边界场景：什么时候真得用 insmod？
只有两种情况值得考虑 insmod：一是调试刚编译好的模块（路径在当前目录，还没 install 到 /lib/modules）；二是嵌入式板子上没生成 modules.dep，又确定模块完全孤立（比如裸机 LED 驱动）。
- 临时加载本地模块：
sudo insmod ./mydrv.ko（注意必须是当前路径或绝对路径） - 加
-v看详细输出：sudo insmod -v ./mydrv.ko - 用
--dry-run模拟加载：sudo insmod --dry-run ./mydrv.ko，提前发现符号缺失问题 - 别用
-f强制加载——它绕过 vermagic 校验，极易导致 oops，尤其在内核版本不一致时
真正麻烦的不是命令本身，而是依赖关系和内核符号的隐式绑定。一个模块能否加载，取决于 modules.dep 是否完整、vermagic 是否吻合、固件是否就位、PCI 设备是否被识别——这些信息全藏在 dmesg 里，而不是命令返回码中。
