[db:标题]

目录一 前言二 背景三 原因分析及措施硬件原因应用软件操作系统四 分析定位转机拨云见雾irq计数Schedstatcoreclk现象结论五 原因一六 原因二七 解决八 结语 一 前言 在上一篇博文中，我们详细介绍了Xenomai的看门狗机制。本文将带您深入了解一个与之相关的真实事故现场及其问题定位过程。为了专注于技术细节，本文去除了所有与具体业务相关的信息，其中的xenomai问题定位思路具有一定借鉴意义，希望对你定位xenomai问题有所帮助。 二 背景 简单介绍一下背景，这是一个基于xenomai的linux实时嵌入式系统，为方便表述，使用设备A代替，使用的是linux5.4+ipipe，CPU为单核 ARMv7(32位)。其上面跑了一个中大型实时应用，其中包含优先级!0且优先级不一的实时任务有25+，这些实时任务其中之一是个TCP/IP协议栈，可见业务之复杂。 该系统上市一年多，期间未出现问题，后来在多个不同现场出现"死机"，不同现场前后间隔几天集中爆发，且毫无规律，出现间隔时长从数日至一两个月不等，令人捉摸不透。初步排查期间没有对系统升级，虽然应用在升级迭代，但经详尽检查后未发现会导致死机的应用变更，很是费解。 期间我们尝试搭建与现场一样的环境，复制了同样设备连接和网络环境均未复现，对现场的网络包进行抓包分析未见异常，这一系列的结果令人倍感困惑。 三 原因分析及措施 在第一个客户现场A发生“死机”发生时，与市场人员沟通初步排查反馈是：系统无正常响应，linux系统ip ping无响应，实时任务的tcpip协议栈的ip ping也无响应。既然搭建与现场一样的环境也无法复现，只能从多方面推导可能的原因，逐一验证猜想，有如下几个方面。 硬件原因 第一个是硬件层面，怀疑现场可能存在干扰，或者硬件存在物料替换导致的系统死机，但经过硬件和EMC现场排查测量未发现问题，加不同程度干扰也未复现。硬件回溯不存在大的物料替换，且发生问题的硬件是不同批次，排除物料导致的问题。硬件排查无果，转而怀疑软件系统问题。 应用软件 怀疑高优先级任务存在bug，如果高优先级任务存在某些触发条件触发（也包括xenomai内核实时任务）进入while(1)死循环逻辑，不释放CPU，会导致的低优先级任务饿死，对外表现就是死机。 熟悉xenomai的朋友都知道，xenomai是一个双内核操作系统，Linux内核是实时核的idle任务，而xenomai又没有PREEMPT-RT那样的实时限流(RT Throttling)机制，只有在实时核调度的实时任务都让出CPU后Linux调度的普通任务才能得到运行，这意味着Linux基本调试手段如串口终端、telnet、ping、coredump、存储IO等等在该情况下会完全失效。这种情况发生时，对外表现就是死机，同时也影响对系统的进一步观测和分析。 而上一篇博文中提到的xenomai watchdog，在我们的系统中并未打开，也就不能确定是该原因导致的死机，否则xenomai watchdog会及时将while(1)死循环逻辑实时任务杀死。 由于实时任务的tcpip协议栈的ip ping也无响应，说明出问题的只能是比tcpip协议栈优先级更高的任务，对此我们对满足条件的实时任务执行流进行了排查，未查找到可能的异常点。 为此我们给现场A发布了临时版本，启用xenomai watchdog，同时添加linux内核coredump，增加另一个更高优先级的任务周期检测应用是否异常等措施，现场A刷机后只能等待复现，但刷机后，该现场不出现了，原本一周左右就能复现，同事出差现场蹲了两周仍未复现!！！而没过几天，而远在千里之外的现场B出现了同样的问题，也只能暂时刷机等待复现。 操作系统 接下来是最后一个可能原因，操作系统可能完全挂了（panic）,但产品没有串口终端、没有调试接口，这个原因更不好求证。我们的产品对外只有一个网口和几个状态灯，只能使用最原始的办法，点灯或者在网络接收中断中添加调试手段，当接收到特定网络包时，直接替换源mac后通过网口发送出来，这样能表明系统没挂，但由于现场复现周期变长，导入也不能立即见效，此时比较担心的是如果真是系统挂了，不知道触发原因，该如何定位? 四 分析定位 转机 以上措施只能被动等待，事情迎来转机是同事的一次发现和现场C的出现。 在前文中，我们介绍了Xenomai的调度逻辑。如果一个高优先级任务（包括Xenomai内核实时任务）在某些触发条件下进入while(1)死循环，不释放CPU资源，会导致低优先级任务饿死，并使得Linux系统的所有输入输出无响应，表现为系统死机。经过应用同事的验证，这一逻辑是正确的。