启用PREEMPT_RT后CAN通信异常的技术咨询

首先明确：这种CAN通信异常的情况绝对不是正常现象，PREEMPT_RT补丁的核心目标是提升系统实时性，不会刻意破坏原有外设的正常工作，大概率是补丁适配或内核配置环节出了问题，下面给你梳理几个具体的排查方向：

• 补丁版本不匹配的潜在风险
  你当前用的是Linux 5.15.52内核，但打的是5.15.55版本的RT补丁。虽然同属5.15系列，但小版本之间的内核代码差异（比如调度器、驱动层的细微修改）可能导致RT补丁打上去后出现兼容性问题——RT补丁对内核的修改非常精细，哪怕几行代码的差异都可能引发隐藏bug。建议你要么找到对应5.15.52版本的RT补丁，要么把内核升级到5.15.55后再打补丁，尽量保证内核和RT补丁的版本完全匹配。

• CAN驱动的RT适配问题
  iMX6ULL使用的是FlexCAN控制器，部分旧版本的FlexCAN驱动可能没有完全适配PREEMPT_RT的调度机制。你可以检查几个点：

  1. 确认内核配置中CONFIG_CAN_FLEXCAN是否正常开启，同时看看有没有和RT相关的CAN配置项（比如CONFIG_CAN_RAW_RT这类实时通信相关的选项）是否启用；
  2. 有些驱动在PREEMPT_RT下需要调整锁的使用方式（比如从自旋锁转为可抢占的mutex），如果驱动没做适配，可能会导致死锁或者调度延迟，进而影响CAN通信；
  3. 可以尝试查找针对iMX6ULL FlexCAN的RT适配补丁，或者升级Yocto中对应的CAN驱动版本。

• 实时调度优先级与中断配置
  PREEMPT_RT会将大部分硬中断转为线程化中断，这可能影响CAN控制器的中断响应效率：

  1. 用ps aux | grep can找到CAN相关的内核线程，再用chrt -p <线程PID>查看它的调度优先级，确保CAN线程的实时优先级足够高（比如设置为90以上的FIFO优先级）；
  2. 检查系统中断配置，用cat /proc/interrupts找到CAN控制器对应的中断号，确认它是否被正确线程化（PREEMPT_RT下中断线程名一般是irq/<PID>-<中断号>），如果中断处理线程优先级不够，会导致CAN帧处理不及时。

• 调试与排查步骤
  为了更精准定位问题，你可以做这些调试：

  1. 查看系统日志：执行dmesg | grep -i can或者journalctl -k | grep CAN，看看有没有驱动初始化失败、帧丢失、总线错误这类关键报错信息；
  2. 检查CAN接口状态：用ip -d link show can0（假设你的CAN接口是can0）查看比特率、错误计数器、总线状态等参数是否正常；
  3. 最小系统测试：暂时禁用其他非必要的外设和服务（比如RTC之外的其他模块），只保留CAN和基础系统，看问题是否依然存在，排除其他组件的干扰。

如果能提供更具体的异常现象（比如是无法收发、频繁丢包还是总线报错）、系统日志里的错误信息，或者CAN驱动的具体版本，能帮你更快定位问题。

备注：内容来源于stack exchange，提问作者akash