lsmod仅显示当前内存中活跃模块的实时快照，不记录加载时间、顺序或失败详情；真正追溯模块行为需结合dmesg（内核ring buffer日志）和journalctl（用户态操作记录）。
lsmod 只显示当前快照，不记录历史加载过程
执行 lsmod 得到的是内核当前内存中活跃模块的实时状态，它读取的是 /proc/modules 这个虚拟文件，**不保存任何时间戳、加载顺序或失败日志**。也就是说，你无法从中得知“哪个模块是刚加载的”“谁触发了加载”“上次加载失败在哪一行”。
dmesg 是查看模块加载行为的真正源头
内核每次加载或卸载模块时，都会在 ring buffer 中打印一条消息，dmesg 就是读取这个缓冲区的命令。关键点在于：
- 模块成功加载时，通常输出类似：
nvidia: loading out-of-tree module taints kernel.或nvme 0000:01:00.0: enabling device (0000 -> 0002) - 加载失败时，错误更明显：
insmod: ERROR: could not insert module ./hello.ko: Invalid module format或module verification failed: signature and/or required key missing - 用
dmesg | tail -30查最近动作；用dmesg | grep -i "nvidia\|nvme\|usb"过滤关键词；用dmesg -T | grep "modprobe"（带本地时间）定位人为操作时间点
systemd-journal 可补全用户级触发记录
如果你是通过 modprobe、systemctl 或开机自动加载触发的模块，journalctl 会记录这些调用上下文：
-
journalctl -u systemd-modules-load.service—— 查看开机时从/etc/modules-load.d/加载模块的日志 -
journalctl /usr/bin/modprobe—— 找到所有手动执行modprobe的记录（含参数和返回码） -
journalctl -k | grep -E "(insmod|rmmod|modprobe)"—— 混合内核与用户态日志，确认是谁发起了操作
注意：默认 dmesg 缓冲区只保留最近几千行，重启后清空；而 journalctl 是否持久化取决于 Storage= 配置（常见为 volatile 或 persistent）。
模块加载失败时，别只盯 lsmod 输出
一个模块没出现在 lsmod 列表里，不代表它没被尝试加载过——很可能卡在签名验证、依赖缺失或硬件 probe 阶段。此时必须交叉查：
- 运行
sudo modprobe -v nvidia（加-v显示详细步骤），看卡在哪一步：找文件？解依赖？调 init 函数？ - 检查
modprobe --showconfig | grep -A5 'blacklist nvidia'，确认是否被配置屏蔽 - 查签名：
modinfo -F sig_id nvidia有输出才表示签名有效；若为空且内核启用了CONFIG_MODULE_SIG_FORCE=y，加载必然静默失败 - 最后再翻
dmesg | tail -20，真正的错误提示几乎总在那里
模块加载不是原子操作，lsmod 只是终点站牌，而 dmesg 和 journalctl 才是行车日志和调度指令单。
