内核调试AI工作流：ftrace / perf / kdump 怎么让AI帮上忙

我以前认为内核调试是 AI 最难帮上忙的领域——这种活儿太"野"，每个 bug 都是孤例，套路化程度低。

直到 64ms 抖动事件彻底改变了我的看法。简单说：i.MX 8M Plus 上一个音频项目，应用层每隔 60-90ms 就丢包一次。我们排查了一周，最后是把 ftrace 输出（30 万行）+ perf top 数据 + dmesg 一起喂给 Claude，它 5 分钟指出根因是 CPU0 的 RT 进程 starve 了 watchdog softirq。

那次之后我系统地调整了内核调试的工作流。今天讲怎么让 AI 真正参与到 ftrace / perf / kdump 这些重量级调试工具中。

预警：本文假设你已经会用 ftrace / perf / kdump。如果你还不会，先看内核 trace docs。

一、为什么内核调试是 AI 加速的好场景

之前有一段时间我也以为 AI 不行——因为内核调试看起来太"靠经验"。后来发现是我没找到正确的姿势。AI 在内核调试上的强项：

1. 处理大量结构化数据

ftrace 一个 trace.dat 几百 MB、几百万行——人不可能逐行看。AI 能在几秒内做模式识别。

2. 跨工具关联

ftrace + perf + dmesg 三份数据放一起看，关联出"同一时刻 A 在做什么 + B 在做什么"。这种事人做累，AI 做轻松。

3. 知识检索

"这个 OOPS 在 mainline 5.15 是 commit xxx 修复的"——AI（特别是有 web search 的）查得比 Google 准。

4. 假设排序

"这种 symptom 可能的原因有 5 种，按概率排序"——这类"可能性枚举"是 AI 的强项。

5. 输出格式化

把 ftrace 数据做成时序图、热力图——AI 写 matplotlib / plotly 比你快 10 倍。

AI 不擅长的

示波器

结论：AI 当你的 trace 数据分析师 + 知识检索助手，决策权在你。

二、整体工作流

1. 现象描述         ← 你
2. 数据采集         ← 你 + AI 帮选 trace points
3. 数据预处理        ← AI（脚本生成）
4. 假设生成 + 排序   ← AI（基于数据 + 知识）
5. 验证假设         ← 你（可能要再采集）
6. 根因确认         ← 你
7. 修复方案         ← 你 + AI 配合

下面分别展开。

三、Step 1-2：现象描述 + 选 trace points

让 AI 帮你设计 trace 策略

Prompt 模板：

现象：
- 平台：i.MX 8M Plus，4 核 A53 @ 1.6GHz，Linux 5.15.71 + RT patch
- 应用：4 路音频采集（48kHz / 24bit / 双声道），通过 ALSA 拿数据
- 问题：每 60-90ms 丢包一次，每次丢 1-2ms 数据
- 复现：稳定可复现，但只在系统加载时（CPU 占用 ~70%）发生
- 已尝试：CPU isolation 没用、把进程绑到 CPU3 也没用

我想用 ftrace 抓数据。请告诉我：
1. 应该开哪些 events / tracers
2. buffer size 怎么设
3. 怎么 trigger（手动 / 触发器 / 脚本）
4. 大约能抓多大数据量、需要分析哪几个维度

AI 一般会给出：

建议开启：
- function_graph tracer，filter 调度相关函数
- events: sched_switch, sched_wakeup, irq_handler_entry/exit, softirq_entry/exit
- events: workqueue_*（看是否是 wq starve）
- events: hrtimer_*
- 可选：trace_printk in 你的音频驱动

trigger：用 trace-cmd record -e ... -p function_graph -l <funcs>，跑 5 秒采集大约 200-500MB

分析维度：
1. 每个丢包时刻前 100ms，CPU3 上发生了什么
2. softirq 是否被高优先级任务挤掉
3. 中断关闭最长持续时间
4. preempt off 区间分布

我以前自己想 trace 策略可能漏掉一半。AI 的覆盖度更全。

自动生成 trace-cmd 命令

基于上面的策略，给我可直接运行的 trace-cmd 命令。
要求：
- 每个 trace session 5 秒
- 保存到 /tmp/trace-${TIMESTAMP}.dat
- buffer per CPU 100MB
- 触发条件：用户态 trigger（写 /sys/kernel/tracing/trace_marker）

输出：

sudo trace-cmd record 
  -e sched_switch -e sched_wakeup 
  -e irq_handler_entry -e irq_handler_exit 
  -e softirq_entry -e softirq_exit 
  -e workqueue_execute_start -e workqueue_execute_end 
  -e hrtimer_expire_entry -e hrtimer_expire_exit 
  -p function_graph 
  -l 'schedule,__schedule,wake_up_process,*_irqsave,*_irqrestore' 
  -B audio -b 102400 
  -o /tmp/trace-$(date +%s).dat 
  sleep 5

复制粘贴就能跑——这种"我懂但要查文档"的命令，AI 一秒给到位。

四、Step 3：数据预处理

ftrace 原始 dat 文件 AI 不能直接看（二进制）。要先 trace-cmd report 转文本，再做处理。

让 AI 写预处理脚本

trace-cmd report 输出的格式如下：

       tasks-1234  [003] d.h2  1234.567890: sched_switch: prev_comm=tasks ...
       
请写 Python 脚本：
1. 解析每行：timestamp / cpu / pid / event / params
2. 对每个 sched_switch，计算 task 在 CPU 上运行了多久
3. 找出"runtime > 5ms" 的任务（候选 hog）
4. 找出"runtime > 1ms 且优先级 > 50" 的任务（潜在 RT hog）
5. 找出 IRQ disable > 100us 的区间
6. 找出 preempt disable > 100us 的区间
7. 输出 JSON，按时间分桶（每 10ms 一桶）

AI 写的脚本一般 100-200 行，跑 1GB ftrace 数据约 1-2 分钟。比我自己写至少省 4 小时。

预处理后的数据形态

{
  "buckets": [
    {
      "t_start": 1234.560,
      "t_end": 1234.570,
      "cpu0": {"top_tasks": [{"comm": "audio-rt", "ms": 8.2}], "irq_off_max_us": 230},
      "cpu3": {"top_tasks": [{"comm": "kworker/3:1H", "ms": 4.5}], "irq_off_max_us": 45},
      ...
    }
  ]
}

这种结构化数据 AI 处理起来轻松——比让它分析原始 trace 快 10 倍、准确率高 5 倍。

五、Step 4：假设生成 + 排序

这是 AI 最强的环节。

Prompt

分析这份 ftrace 预处理数据：

<贴 JSON>

业务现象：每 60-90ms 出现一次音频丢包。

请做：
1. 找出与丢包时刻强相关的内核活动（前 5ms 时间窗）
2. 列出 5 个最可能的根因，按可能性排序
3. 每个根因给出"如果是这个，下一步怎么验证"
4. 不确定的地方明确说明"需要更多数据"

AI 输出大致：

强相关活动：
- 每次丢包前 2-3ms，CPU0 上 sshd 进程运行了 8-12ms（被 SCHED_FIFO 优先级 51 的 audio-rt 抢占了，但 audio-rt 自己也跑了 3ms）
- CPU3 在丢包时刻 IRQ 被关闭了 280us（来自 i2c_imx 驱动的 transfer 函数）

可能根因（按概率）：

1. [60%] CPU0 上 sshd 阻塞了 ksoftirqd/0，network softirq 堆积导致 SDMA 中断处理延迟
   验证：抓 softirq 在 sshd 运行期间是否累积、ksoftirqd/0 的 wakeup 时间

2. [20%] i2c_imx 的 mutex / IRQ disable 时间过长
   验证：开 lockdep / lock_stat，看 i2c_imx 的临界区时长分布

3. [10%] hrtimer 调度抖动
   验证：trace_printk 在音频中断 ISR，看 ISR 触发的 jitter

4. [5%] memory pressure
   验证：开 mem_pressure tracer

5. [5%] 其他（cache thrash / DDR 时序）
   验证：perf top 看 cache miss 率

按 1 验证后果然是这个原因——sshd 跑 telemetry 时占满 CPU0，softirq 没机会跑。把 sshd cgroup 限制 CPU 后丢包消失。

5 分钟出根因。我们之前花了一周。

六、perf 数据分析

跟 ftrace 类似，但侧重不同。perf 适合：

IPC

让 AI 解读 perf report

perf record -g --call-graph dwarf -F 999 -p $PID sleep 30
perf report --stdio > perf.txt

把 perf.txt（前 500 行）丢给 AI：

这是一个音频处理进程的 perf report：
<贴前 500 行>

业务背景：进程做 4 路音频实时混音，CPU 占用率 80%。我希望降到 60% 以下。

请：
1. 找出热点函数
2. 哪些热点是"正常"的（业务必须）
3. 哪些热点可能是"代码效率问题"
4. 给出优化方向（不要给具体代码，只给方向）

AI 输出会指出：

热点 #1: alsa_lib_pcm_writei (45%) — 这是 ALSA write，正常

热点 #2: __memmove_neon (18%) — neon 加速的 memmove，但调用太频繁。检查是否有不必要的 buffer copy（zero-copy 优化空间）

热点 #3: pthread_mutex_lock (8%) — 锁竞争。看看 lock 粒度能否降低

热点 #4: clock_gettime (5%) — 调用过多。考虑缓存时间戳

每条都给方向，不给代码。给方向就够了——具体优化要工程师上手做。

火焰图

让 AI 写脚本生成火焰图：

基于上面的 perf 数据生成火焰图（用 brendangregg 的 FlameGraph）。
脚本：从 perf.data 一键生成 SVG。

AI 给出：

perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > flame.svg

我手动改了 stack collapse 的参数。5 分钟出图。

七、kdump 分析

最难的活儿——内核挂了，要从 vmcore 里找原因。

基础环境

# 配置 kdump
sudo apt install kdump-tools crash
echo "crashkernel=128M" | sudo tee -a /etc/default/grub
update-grub && reboot

Crash 结合 AI

crash 命令进交互模式后，把关键输出复制给 AI：

crash> bt
PID: 1234   TASK: ffff800012345678  CPU: 2   COMMAND: "audio-rt"
#0 [...]  panic
#1 [...]  oops_end
#2 [...]  __die
 ...
#8 [...]  iio_read_channel_raw

crash> log | tail -50
[...]
[12345.678] BUG: kernel NULL pointer dereference, address: 0000000000000018
[...]

crash> dis -l <RIP>
0xffff800012345abc <iio_read_channel_raw+0x14>: ldr x1, [x0, #24]

把这些丢给 AI：

我在分析一个 NULL deref kernel panic：

【backtrace】
<贴 bt>

【dmesg】
<贴 log>

【panic 处汇编】
<贴 dis 输出>

【源码上下文】
<贴 iio_read_channel_raw 函数>

请：
1. 哪个变量是 NULL
2. 这个变量为什么会是 NULL（设备未 probe / 已 release / race）
3. 列出 3 个最可能的代码 bug
4. 给出修复方向

AI 一般能猜中 80%。剩下 20% 它会承认"信息不够，建议提供 X"。

重要：vmcore 不能整个传给 AI

vmcore 几百 MB 全给 AI 没意义。你要做的是把 crash 命令的关键输出（bt / log / ps / mod / kmem -i 等）选择性给 AI。

八、几个真实案例

案例 1：音频丢包 64ms

工具：ftrace + 我们的预处理脚本 + Claude

时长：5 分钟（vs 之前 1 周）

根因：sshd telemetry 阻塞 ksoftirqd

修复：cgroup 限制 sshd CPU + IRQ affinity 调整

案例 2：rcu_sched stall

工具：dmesg 关键 stack + AI 检索

我看到：

rcu: INFO: rcu_sched self-detected stall on CPU
[...]  pwrite64+0x1c
[...]  i2c_smbus_xfer

丢给 AI："这个 stall pattern 你见过吗？"

AI 答：

这是经典的 i2c bus stuck on long transaction。i2c-imx 在 5.15 内核有个 known issue（commit xxxxxxx 修复），影响是当 slave NAK 时 driver 不正确地 retry，导致整个事务持续几秒。建议 backport。

cherry-pick 那个 commit 后再没遇到。AI 帮我省了至少两天的 git log 翻找。

案例 3：Memory leak（slab）

工具：/proc/slabinfo 长时间采样 + AI 趋势分析

# 每分钟采一次
while true; do
  cat /proc/slabinfo > /tmp/slab-$(date +%s).txt
  sleep 60
done

跑 24 小时，把 1440 份数据合并成 csv 给 AI：

分析过去 24 小时 slabinfo 趋势，找出持续增长的 slab：
<贴 csv>

每个 slab 给：
- 总增长率（KB/h）
- 是否线性增长（leak 特征）
- 这个 slab 通常被哪些代码使用
- leak 嫌疑等级

AI 锁定 vm_area_struct 持续涨——是某个用户态进程 mmap leak。用 eu-stack -p $PID 抓栈定位到具体代码。

九、经验

1. AI 给的"看起来正确"的分析必须验证

AI 经常会说："X 是根因，因为 Y 数据显示 Z"。Z 经常是 AI 编的——它没真的在数据里看到。

修复方式：要求 AI 给出"具体证据"——哪个时间戳、哪个 CPU、哪个函数。然后你回去 grep 一下数据看真的有没有。

我有过 3 次踩坑：AI 言之凿凿说"sched_switch 显示 X"，我回去 grep 发现根本没这个 event。

2. 不要让 AI 直接看 raw trace

不要把 100MB 的 trace.txt 整个塞给 AI——它读不完，会"假装读完"然后 hallucinate。

正确：先用脚本预处理，把数据降维到几 KB 的 JSON，再给 AI。

3. 优先级：dmesg > trace > perf > kdump

排查顺序：

dmesg 关键字检索（OOPS / BUG / WARN）—— 30 秒

ftrace 关键 events（sched / irq）—— 5 分钟采集 + 5 分钟分析

perf 热点（性能问题才需要）

kdump（必须的最后手段）

AI 在每一步都帮得上忙，但越往下投入越大。先做轻的。

4. trace 数据和源码一起给

只给 trace 数据，AI 只能猜行为。同时给相关源码 + DT + Kconfig，AI 能给具体的代码层根因。

5. 内核 mailing list 是 AI 的好朋友

很多 bug 在 lkml 已有讨论。AI 检索 lkml + 内核 git log 比你 Google 强。要充分利用。

十、什么调试场景不该用 AI

硬件信号问题（电平 / 时序 / 噪声）—— 必须示波器

物理布线问题（焊点虚焊 / 接触不良）

多机分布式 race condition —— AI 看不全

跨 hypervisor 的虚拟化 bug —— 太罕见，AI 知识盲区

Secure World / TrustZone 问题 —— ARM TF-A / OP-TEE 的 bug 极少见，AI 知识不够

这些场景 AI 给的建议大概率是错的，要警惕。

十一、ROI 排序

高 ROI

dmesg / OOPS / BUG 关键字 + AI 检索 lkml —— 即时见效

ftrace 数据预处理脚本（让 AI 写） —— 一次写好长期用

AI 假设排序（基于预处理数据） —— 复杂 bug 加速 5-10 倍

中 ROI

perf 热点优化建议slabinfo / meminfo 长时间趋势分析kdump backtrace + AI 推理

低 ROI

AI 直接读 raw trace（hallucination 风险大）

AI 写内核驱动 patch fix（没 review 不能信）

完全替代你的内核知识（永远做不到）

十二、写在最后

内核调试是嵌入式工程师的核心壁垒。AI 不会让这个壁垒消失，但会让你的产能翻几倍。

最关键的认知转变：AI 不是替你调试，是让你成为"超级 trace 分析师"——它处理你处理不完的数据量、检索你检索不完的知识库、提出你来不及枚举的假设。

而最终的"啊，我懂了"那一刻，依然只能发生在你脑子里。

如果你目前调试只看 dmesg，从今天起把 ftrace 用起来——它和 AI 的组合是嵌入式工程师 2026 年最值得投资的技能组合。