不能直接看到。systemd-analyze blame --all 仅显示 systemd 管理的 unit（如 .service、.mount），而内核驱动在 kernel 阶段由内核自身加载，不作为 unit 出现；其耗时归入 systemd-analyze time 的 kernel 阶段，需结合 initcall_debug 和 printk.time=y 通过 dmesg 定位具体初始化函数耗时。
systemd-analyze blame --all 能看到驱动加载耗时吗
不能直接看到。systemd-analyze blame 列出的是 systemd 管理的 unit（如 .service、.mount、.device），而大多数内核驱动（比如 nvme、igb、drm_kms_helper）是内核模块，在 kernel 阶段由 modprobe 或 initramfs 内部逻辑加载，不作为独立 unit 出现在 userspace 启动链里。所以你在 blame 输出里找不到“xxx.ko 加载花了 800ms”这种条目。
真正能反映驱动加载时间的，是 systemd-analyze time 中的 kernel 阶段总耗时——它包含了从内核解压完成到 systemd 进程（PID 1）启动前的所有动作，其中就包括：设备探测、驱动初始化、子系统注册等。如果 kernel 时间异常高（比如 > 1.5s），那大概率是某几个驱动在初始化阶段卡住了，而不是加载慢。
怎么定位具体哪个驱动拖慢了 kernel 阶段
靠内核日志里的时间戳和 initcall 调试。Linux 内核自带机制可以记录每个初始化函数（initcall）的执行耗时，前提是启动时加了对应参数：
- 重启时在 GRUB 编辑界面按
e，找到以linux开头的行，在末尾添加：initcall_debug printk.time=y - 按
Ctrl+X启动，等系统起来后执行：dmesg | grep "initcall\|time\|start_kernel" - 重点关注形如
initcall xxx_init+0x0/0xXXX returned 0 after 423 msecs的行——这就是某个驱动或子系统的初始化耗时
注意：initcall_debug 会显著拖慢启动（尤其在有大量驱动的服务器上），只用于诊断，别长期开启；printk.time=y 让每行日志带时间戳（单位是秒.毫秒），方便比对先后顺序。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
/proc/sys/kernel/printk_devkmsg 和 dmesg 时间精度问题
dmesg 默认输出的时间戳是“自内核启动以来的秒数”，精度只有秒级，对定位毫秒级卡顿没用。要获得更准的时间信息，必须：
- 确认
/proc/sys/kernel/printk_devkmsg值为on或always（不是off），否则部分早期日志可能被丢弃 - 用
dmesg -T（显示本地时间）或dmesg -t（显示微秒级时间差）辅助判断，但最可靠仍是printk.time=y+initcall_debug组合 - 某些驱动（如 NVMe、RAID 卡）会在初始化失败时重试多次，每次重试都记日志，这时要横向比对同一驱动名下多条
returned after X ms的记录，看是否集中在某次重试
initramfs 里的驱动加载怎么查
如果驱动是在 initramfs 阶段加载的（比如加密卷依赖的 dm-crypt、LVM 依赖的 dm-mod），systemd-analyze time 里归入 initrd 阶段，但具体哪个模块慢，得进 initramfs 环境查：
- 用
lsinitcpio /boot/initramfs-*.img | grep -E "(ko|ko.xz)"看哪些驱动被打了进去 - 临时修改 initramfs：解包 → 在
init脚本开头加echo "$(date +%s.%N) start init"类似语句 → 重新打包 → 重启抓串口或journalctl -b -t kernel（如果 initramfs 支持 journal） - 更简单的方法：在启动时加内核参数
rd.debug，它会让 dracut 在 initramfs 阶段输出详细时间日志，最终也会落到dmesg里
真正难啃的点不在命令怎么敲，而在你得区分清楚：这个“驱动慢”到底是模块加载慢（极少）、初始化函数卡住（常见）、还是等待硬件响应超时（比如网卡 PHY 没 link up 就死等）。三者对应的日志特征、排查路径和修复方式完全不同。
