Page-1

# 概述子系统是在 Qualcomm^®^ SoC 上拥有自己独立执行环境的处理器。本指南介绍了受影响子系统的工具、示例日志和故障排除方法。当用户必须诊断和排除此类异常时，了解子系统中出现的差异以及检查错误的方法会非常有用。下表列出了SoC上的重要子系统。表：SoC上的子系统 | 子系统 (Subsystem) | 说明 | | --- | --- | | 应用处理器子系统 (APSS) | 这是主要子系统。它将 Linux 内核作为 high-level OS (HLOS) 来运行。 | | 应用数字信号处理器 (aDSP) | 该子系统也称为低功耗音频子系统 (LPASS)。该子系统处理音频编码/解码和语音识别等数字信号处理任务。 | | 计算数字信号处理器 (cDSP) | 该子系统也称为计算 DSP。该子系统适用于计算密集型任务，例如神经网络相关的计算。 | | Qualcomm^®^ 受信任执行环境 (TEE)/TrustZone (TZ) | 该子系统执行安全操作，并基于 Arm® TrustZone® 架构构建。关于此子系统的更多信息，请参阅 [Qualcomm Linux 安全指南](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-11)。 | | 无线局域网处理器子系统 (WPSS) | 该子系统管理连接Wi-Fi网络、发送和接收数据包、处理安全协议以及确保网络性能稳定的任务。关于此子系统的更多信息，请参阅 [Qualcomm Linux Wi-Fi 指南](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-14/introduction.html)。 | | Always On 处理器 (AOP) | 该子系统可以调节设备的电源。 | 除应用处理器外，所有其他子系统的软件也被称为非 HLOS。要了解子系统的启动流程，参见 [Qualcomm Linux 启动指南](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-4)。 Note 请参阅 Qualcomm^®^ Linux^®^ 上支持的[硬件 SoC](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-115/soc.html)。 ## 调试工作流由于 Qualcomm SoC 上存在多个子系统，因此首先确定出现问题的子系统非常重要，以便您可以调试相关子系统。应用处理器作为主要子系统可以检测其他子系统何时发生崩溃。例如，如果 aDSP 处理器子系统崩溃，则内核日志会捕获子系统重启 (SSR) 崩溃错误日志。因此，要识别待调试的子系统，您必须首先验证内核调试消息。下图展示了识别错误的工作流程以及要调试的组件。 **图：识别受影响子系统的工作流程** 当内核 dmesg 日志中没有 panic 标识特征时，请验证 Qualcomm TEE 诊断 (diag) 日志中是否存在错误，如不安全看门狗 Bite 和片上网络 (NoC) 错误。以下主题描述了一些示例内核消息，这些消息指示内核 panic、bug 和子系统崩溃问题。 ### 识别内核 panic 和 bug 从内核 dmesg 日志中，您可以确定该重置是内核 panic 还是 bug。以下是一些指示内核 panic 或 bug 的示例日志： - Panic（模式：一般错误） 18.800936: <6> Kernel panic - not syncing: Fatal exception 18.800938: <6> SMP: stopping secondary CPUs 18.800947: <6> CPU0: stopping Kernel panic - not syncing: Apps watchdog Bark received! - Bug（模式 1：由于内存损坏而强制崩溃） 12.899532: <6> BUG kmalloc-128 (Not tainted): Redzone overwritten 12.905418: <6> ----------------------------------------------------------------------------- - Bug（模式 2：驱动程序强制崩溃） 320.510769: <6> ------------[ cut here ]------------ 320.510781: <6> kernel BUG at /local/mnt/workspace/lnxbuild/project/trees\_in\_use/free\_tree\_platform\_manifest\_refs\_tags/drivers/platform/msm/ipa/ipa\_v3/ipa\_qmi\_service.c:955! - Bug（模式 3：由于锁定问题而强制崩溃） [ 180.993861] BUG: spinlock lockup suspected on CPU#0, swapper/0/0 [ 180.993883] lock: stop\_lock+0x0/0x18, .magic: dead4ead, .owner: swapper/6/0, .owner\_cpu: 6 [ 181.015629] Causing a watchdog bite! Note 大多数 bug 之后都会发生内核 panic。关于调试内核问题的更多信息，请参阅 [Qualcomm Linux 内核指南](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-3/overview.html)。 ### 识别子系统崩溃问题请验证内核 dmesg 日志，以便确定重启是否是由子系统崩溃引起。例如，根据 `qcm6490.dtsi`（node：remoteproc\_adsp：remoteproc@3000000），以下日志表明aDSP子系统崩溃。 0x000000000A27652C | 5198.790423: qcom\_q6v5\_pas 3000000.remoteproc: fatal error received: err\_inject\_crash.c:413:Crash injected via Diag 0x000000000A276689 | 5198.801061: remoteproc remoteproc2: crash detected in 3000000.remoteproc: type fatal error 0x000000000A2767A1 | 5198.809602: remoteproc remoteproc2: handling crash #1 in 3000000.remoteproc 0x000000000A27688E | 5198.816837: remoteproc remoteproc2: recovering 3000000.remoteproc 0x000000000A276971 | 5198.823784: qcom\_q6v5\_pas 8a00000.remoteproc: subsystem event rejected ### 从 Qualcomm TEE 日志中识别系统问题此功能可供具有授权访问权限的许可开发者使用。关于指示 Qualcomm TEE 中错误的示例日志，请参阅 [Qualcomm Linux 调试指南 - 附录](https://docs.qualcomm.com/bundle/resource/topics/80-70017-12A/identify_subsystem_to_be_debugged.html#identify_and_debug_errors_in_tz)。如果 Qualcomm TEE 诊断日志中没有错误，则很可能是安全看门狗 Bite 问题。关于看门狗问题的更多信息，请参阅[硬件重置](https://docs.qualcomm.com/doc/80-70017-12SC/topic/general_system_debugging.html#reset-hardware)。关于 Qualcomm TEE 中调试问题的信息，请参阅 [Qualcomm Linux 安全指南](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-11/debug.html)。 ## 调试方法有两种调试方法： - **目标上调试** 目标上调试是调试软件问题的基本方式。这种方法非常强大，因为大多数信息都可以从实时设备访问。SSH 用于将 Linux 主机连接到现场设备。要设置 SSH，请参阅[使用 SSH](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-254/how_to.html#use-ssh)。关于各种目标调试功能的更多信息，请参阅目标调试功能。 - **目标外调试** 这种调试方法需要日志而不是实际设备，因此是一种方便、高效的调试方法。使用内存 dump 或日志记录工具执行调试。离线调试可使用各种类型的日志。由于 RAM dump 采集了大部分内存区域，但仅采集了有限的硬件寄存器信息，因此，调试与硬件相关的问题可能是一个挑战。关于各种目标外调试功能的更多信息，请参阅[目标外调试功能](https://docs.qualcomm.com/doc/80-70017-12SC/topic/Debug-overview.html#off-target-debug-features)。 ## 目标上调试功能设备上提供了以下调试功能，可以在运行时使用。 - Perf 工具 - 子系统重启 - 强制子系统复位 ### Perf 工具 Perf 是 Linux 中一个功能强大的工具，可以简化性能分析。此工具包含在位于 `tools/perf` 的 Linux 内核中。 Perf 工具可用于调试系统行为的各个方面，包括 CPU 性能计数器、跟踪点、kprobe 和 uprobe（用于动态跟踪）。下表列出了 Perf 工具的主要功能。表：Perf 工具的主要功能 | 功能 | 说明 | | --- | --- | | CPU 性能计数器 | 这些 CPU 硬件寄存器用于跟踪已执行指令、缓存未命中和分支误预测等事件。这些事件构成了分析应用程序和识别性能瓶颈的基础。 | | 跟踪点 | 这些跟踪点放置在代码中的逻辑位置。例如，系统调用、网络事件和文件系统操作。这些跟踪点以最小的开销提供时间戳和堆栈跟踪等信息。 | | 动态跟踪 | 此功能使用 kprobes 和 uprobes 框架动态创建跟踪点。因此，此功能允许在内核空间和用户空间中进行跟踪。 | 有关 Perf 工具的详细信息，参见以下资源： - [https://perf.wiki.kernel.org/index.php/Main_Page](https://perf.wiki.kernel.org/index.php/Main_Page) - [https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md](https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md) - [https://docs.kernel.org/trace/coresight/index.html](https://docs.kernel.org/trace/coresight/index.html) - [https://docs.kernel.org/trace/coresight/coresight-perf.html](https://docs.kernel.org/trace/coresight/coresight-perf.html) ### 子系统重启 (Subsystem restart) 子系统可在崩溃时单独重启，无需设备重启。这种类型的重新启动称为子系统重新启动 (SSR)。SSR 功能是使用 Linux 内核中提供的 Remoteproc 框架来实现的。要启用完整内存 dump 以进行调试，默认情况下禁用 SSR 功能。建议在商用设备上使用 SSR 功能，不要在开发阶段使用。有关 SSR 功能的详细信息，参见 [Remoteproc 子系统](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-3/features.html#remoteproc-subsystem)。启用 SSR 功能后，系统重新启动时会生成 SSR dump。由于 SSR dump 的大小小于完整内存 dump 的大小，因此您可能考虑使用 SSR dump 进行调试。但是，需要整个 RAM dump 来调试某些子系统崩溃。有关如何启用和捕获子系统 dump 的信息，参见[子系统 dumps](https://docs.qualcomm.com/doc/80-70017-12SC/topic/debugging_linux_kernel.html#subsystem-ram-dumps)。 ### 强制子系统复位此功能可用于调试需要重新启动子系统的用例。此功能可供具有授权访问权限的许可开发者使用。要强制重置子系统，可以使用 QXDM Professional^™^ 运行 `diag` 命令。有关 QXDM Professional 命令及其用法的信息，请参阅 [Qualcomm Linux Debug Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70017-12A/debug-non-hlos-subsystems.html#qxdm_professional)。 ## 目标外调试功能用户可以使用 RAM dump 或 QXDM Professional 进行离线调试。 ### RAM dump RAM dump 是发生故障时整个内存的快照。可以使用各种工具来分析RAM dump，包括 Qualcomm崩溃分析门户(QCAP)、RAMParser、Lauterbach TRACE32 模拟器和 Crash utility。关于如何收集和解析 RAM dump 的信息，请参阅[收集和解析 RAM dump](https://docs.qualcomm.com/doc/80-70017-12SC/topic/debugging_linux_kernel.html#collect-and-parse-ram-dumps)。 ### QXDM Professional QXDM Professional 用于调试各种子系统。该工具可供具有授权访问权限的许可开发者使用。有关 QXDM Professional 命令及其用法的信息，请参阅 [Qualcomm Linux Debug Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70017-12A/debug-non-hlos-subsystems.html#qxdm_professional)。 ## 常见系统问题系统问题可以分为以下类型之一： > > > - [Linux 内核空间问题](https://docs.qualcomm.com/doc/80-70017-12SC/topic/debugging_linux_kernel.html#debugging-linux-kernel) > - [系统问题](https://docs.qualcomm.com/doc/80-70017-12SC/topic/general_system_debugging.html#general-system-debugging) > > > > > > > > > - [看门狗问题](https://docs.qualcomm.com/doc/80-70017-12SC/topic/general_system_debugging.html#watchdog-timeout) > > - [总线 hang 和超时问题](https://docs.qualcomm.com/doc/80-70017-12SC/topic/general_system_debugging.html#erroneous-transaction-on-bus-error-and-timeout) > > - [硬件复位问题](https://docs.qualcomm.com/doc/80-70017-12SC/topic/general_system_debugging.html#reset-hardware) ## 其他问题以下是您可能遇到的其他问题： - 由于软件错误导致设备冻结问题 - Linux应用程序相关问题 - 由于 PCB 相关硬件问题导致的随机复位要调试 Linux 内核相关问题，请参阅[调试 Linux 内核空间问题](https://docs.qualcomm.com/doc/80-70017-12SC/topic/debugging_linux_kernel.html#debugging-linux-kernel)。要调试 Linux 应用程序相关问题，请参阅[调试 Linux 用户空间问题](https://docs.qualcomm.com/doc/80-70017-12SC/topic/using_open_source_debug_tools.html#using-open-source-debug-tools)。 Last Published: Jan 23, 2025 [Next Topic 调试 Linux 用户空间问题](https://docs.qualcomm.com/bundle/publicresource/80-70017-12SC/topics/using_open_source_debug_tools.md)