1. 如果某个 Linux 进程内存持续上涨，但没有明显崩溃，你会怎么判断是内存泄漏还是内存碎片问题？

答案：

1. 先看内存上涨的是哪一类内存。通过 top、pmap、smem 或 /proc/PID/status 观察 VmRSS、VmSize、匿名页、文件映射区的变化，确认到底是堆增长、mmap 增长，还是缓存导致的占用上升。
2. 如果怀疑内存泄漏，要看申请和释放是否失衡。可以结合 valgrind、asan、自定义内存统计埋点，检查某些对象是否只申请不释放，或者异常路径、超时路径、错误返回分支里遗漏了释放逻辑。
3. 如果怀疑内存碎片，要看“总内存够但连续可用块不足”的现象。这类问题常见于频繁申请释放不同大小内存的场景，表现为内存占用不一定极端高，但后续分配失败或系统抖动变大。
4. 还要结合业务场景判断。如果是长期运行后缓慢上涨且不可回落，更偏向泄漏；如果是业务高峰后占用高、但申请成功率下降或分配耗时增加，更可能和碎片化有关。

2. 中断上半部和下半部为什么要分开设计？如果不分开，会带来什么问题？

答案：

1. 上半部的核心目标是尽快响应硬件事件。它一般只做最小化处理，比如读状态寄存器、清中断标志、保存关键数据、唤醒后续处理流程。
2. 下半部负责执行耗时或复杂逻辑。例如数据拷贝、协议解析、状态机推进、通知用户态等操作，适合放到 tasklet、workqueue 或线程上下文里做。
3. 如果不分开，中断处理时间会过长。这样会影响系统实时性，导致其他中断响应延迟，严重时还可能让高优先级任务得不到及时调度。
4. 复杂逻辑放在中断里还容易引入更多问题。比如中断上下文不能睡眠、不能调用某些阻塞接口，也更容易造成锁设计混乱、调试困难和系统不稳定。

3. 你怎么理解设备树？它解决了什么问题？

答案：

1. 设备树本质上是硬件描述数据。它把板级硬件信息，例如外设地址、中断号、时钟、GPIO、DMA 通道等，用统一的数据结构描述出来，供内核解析使用。
2. 它把“硬件描述”和“驱动代码”做了解耦。驱动不需要把某块板子的具体资源信息硬编码进代码，而是通过匹配设备树节点读取配置，提高了驱动复用性。
3. 设备树方便支持多板型、多平台。同一套内核和驱动代码，可以通过不同的 .dts/.dtb 适配不同硬件，降低维护成本。
4. 它也让硬件变更成本更低。如果只是 GPIO、中断号、总线地址这类资源变了，很多时候只改设备树，不需要改驱动逻辑本身。

4. 如果一个驱动 probe 失败了，你通常会从哪些方向排查？

答案：

1. 先看设备是否真的枚举到了。确认设备树节点是否使能、compatible 是否匹配、总线设备是否注册成功，避免还没匹配上驱动就误以为 probe 逻辑有问题。
2. 检查资源获取是否正确。重点看寄存器地址、中断、时钟、复位、GPIO、电源这些资源是否从设备树中成功获取，很多 probe 失败其实是资源准备不完整。
3. 看初始化顺序是否有依赖问题。例如时钟没开、电源没上、pinmux 没配好、依赖的 regulator 或 parent device 还没就绪，这些都会导致 probe 早期失败。
4. 结合内核日志定位返回码。-EPROBE_DEFER、-EINVAL、-ENODEV 这些错误码意义不同，前者通常是依赖未准备好，后两者则更像配置错误或设备本身不存在。

5. FreeRTOS 中如果高优先级任务一直运行，会对低优先级任务造成什么影响？怎么避免？

答案：

1. 最直接的问题是低优先级任务可能长期得不到调度。如果高优先级任务一直处于就绪态且不主动阻塞，低优先级任务会出现“饿死”现象。
2. 这种问题通常说明任务设计不合理。高优先级任务不应该一直忙等或死循环轮询，而应该在没有工作时进入阻塞态，例如等待消息、信号量或事件。
3. 可以通过合理划分优