: Modem Crash Recovery与SSR机制)
系列文章目录本文是“骁龙移动平台双卡双待DSDS的技术内幕”系列的第九篇分析双卡场景下Modem异常崩溃的检测、恢复和对双卡业务的影响。1. 为什么DSDS更容易触发Modem异常1.1 DSDS增加的异常风险┌─────────────────────────────────────────────────────┐ │ DSDS 场景下的额外 Modem 压力 │ │ │ │ 1. 状态复杂度翻倍 │ │ - 双 NAS 状态机并发运行 │ │ - 双 IMS 注册维护 │ │ - 双路 Data Bearer 管理 │ │ │ │ 2. 时序约束更严格 │ │ - Tune-away 时间窗口精确到 ms 级 │ │ - RF 切换必须在 HARQ deadline 内完成 │ │ - IMS keepalive 超时可能引发异常恢复 │ │ │ │ 3. 竞态条件增多 │ │ - 两个 Sub 同时请求 RF │ │ - DDS Switch 与 来电同时发生 │ │ - TAU/LAU 与 data transfer 并发 │ │ │ │ 4. 内存/处理器压力 │ │ - Modem DSP 需要同时处理两份协议栈 │ │ - 缓冲区管理更复杂 │ │ - Cache 压力增大 │ └─────────────────────────────────────────────────────┘1.2 常见 Modem Crash 原因 (DSDS 相关)类别具体原因频率竞态条件RF 调度死锁两 Sub 互等资源中状态异常NAS 状态机进入不合法状态中超时Tune-away 超时导致 watchdog低-中内存Modem heap 溢出双栈占用低信令异常网络侧发送不合规消息低硬件RF PLL 锁频失败累积极低2. SSR (Sub-System Restart) 机制2.1 SSR 基本概念┌─────────────────────────────────────────────────────┐ │ SSR 架构概述 │ │ │ │ 传统处理: Modem crash → 整机重启 (用户体验极差) │ │ │ │ SSR 处理: Modem crash → 仅重启 Modem 子系统 │ │ AP/Android 继续运行 │ │ 用户感知: 短暂无网络 → 自动恢复 │ │ │ │ ┌─────────────────────────────────────────────┐ │ │ │ Application Processor (AP) │ │ │ │ ┌────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ │ │ Android│ │ Framework│ │ 其他进程 │ │ │ │ │ │ Apps │ │ │ │ (继续运行) │ │ │ │ │ └────────┘ └──────────┘ └──────────────┘ │ │ │ └───────────────────┬─────────────────────────┘ │ │ │ (通信中断后重建) │ │ ┌───────────────────▼─────────────────────────┐ │ │ │ Modem Processor (BP) ← 被重启 │ │ │ │ ┌────────┐ ┌──────┐ ┌──────────────────┐ │ │ │ │ │ NAS │ │ CM │ │ RF / L1 │ │ │ │ │ │(重新初始化)│ │ │ (重新校准) │ │ │ │ │ └────────┘ └──────┘ └──────────────────┘ │ │ │ └──────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────┘2.2 SSR 触发条件// Modem 侧错误检测机制// 1. Watchdog Timeout// Modem DSP 看门狗超时任务未在预期时间内完成if(modem_task_elapsedWATCHDOG_TIMEOUT_MS){trigger_ssr(SSR_REASON_WATCHDOG);}// 2. Fatal Error (Assert)// 代码中的断言失败ASSERT(nas_state!INVALID_STATE);// - trigger_ssr(SSR_REASON_ASSERT);// 3. Exception (异常中断)// Data abort, undefined instruction 等// - Hardware interrupt - SSR handler// 4. AP 侧检测到通信异常// QMI 心跳超时if(qmi_heartbeat_lost_countMAX_HEARTBEAT_MISS){request_modem_ssr();// AP 主动触发 Modem 重启}2.3 SSR 恢复流程SSR 恢复时序 (DSDS 场景) T0ms: Modem crash detected T10ms: Modem watchdog fires, 通知 AP T50ms: AP 收到 SSR 通知 ├── RIL[0] 收到 MODEM_DOWN 事件 ├── RIL[1] 收到 MODEM_DOWN 事件 ├── Phone[0] 进入 OUT_OF_SERVICE └── Phone[1] 进入 OUT_OF_SERVICE T100ms: Modem重启开始 ├── Modem firmware 重新加载 ├── Modem 初始化 └── QMI 通道重建 T2000ms: Modem重启完成QMI连接恢复 ├── RIL[0] 检测到 MODEM_UP ├── RIL[1] 检测到 MODEM_UP ├── 重新初始化双 QMI Client └── 发送 QMI Bind Subscription T3000ms: 网络注册恢复 ├── Sub0: 使用 RPLMN 快速注册 └── Sub1: 使用 RPLMN 快速注册 T5000ms: IMS重新注册 ├── Sub0 IMS PDN 重建 SIP REGISTER └── Sub1 IMS PDN 重建 SIP REGISTER T8000ms: 业务完全恢复 ├── 数据连接恢复 ├── VoLTE 能力恢复 └── 用户可正常使用 总恢复时间~5-10秒用户感知无网络3. DSDS对SSR恢复的额外影响3.1 双卡恢复的协调单卡SSR恢复 Modem重启 → 单卡注册 → 数据恢复 → IMS注册 时间5-8秒 双卡SSR恢复更复杂 Modem重启 → 双QMI重建 → DDS卡优先注册 → 非DDS卡注册 → 双IMS重注册 → 业务恢复 时间8-15秒 额外考虑 DDS 状态恢复需要确保默认数据卡配置正确 通话恢复如果 SSR 发生在通话中通话会断开 IMS 注册超时网络侧可能已经注销 UE需要完整注册 Bearer 重建所有 EPS Bearer 需要重新建立3.2 通话中 SSR 的处理场景: Sub0 VoLTE 通话中发生 Modem SSR ┌─────────────────────────────────────────────────┐ │ 影响: │ │ ├── 当前 VoLTE 通话立即中断 │ │ ├── 对端听到提示音 │ │ ├── Sub1 待机状态丢失 │ │ └── 用户体验: 突然掉线 │ │ │ │ 恢复策略: │ │ ├── AP 通知用户通话已断开 │ │ ├── 保存通话记录 (时长、号码) │ │ ├── Modem 恢复后优先恢复 IMS │ │ ├── 如果 SSR 恢复很快 (3s), 尝试自动回拨 │ │ │ (部分 OEM 实现, 非标准行为) │ │ └── 否则通知用户手动重拨 │ └─────────────────────────────────────────────────┘3.3 DDS Switch 过程中的 SSR场景正在执行 DDS Switch 时 Modem crash 风险DDS 状态不确定 可能 Sub0 已断开但 Sub1 未连上 Modem 侧 DDS 标记与 AP 侧不一致 恢复后可能出现数据卡配置错误 处理 1. Modem 恢复后AP 重新下发 DDS 配置 「DDS 切换请求」DSD 服务 2. 如果 Modem 恢复后默认 DDS ! AP 期望 强制执行 DDS Switch 到 AP 期望的卡 3. 数据连接恢复按新 DDS 状态执行4. 错误检测与上报4.1 AP 侧错误检测// RIL 层的 Modem 状态监控classRIL{// Modem 通信心跳检测privatestaticfinalintHEARTBEAT_INTERVAL_MS5000;privateintmHeartbeatMissCount0;voidcheckModemAlive(){sendQmiHeartbeat(response-{if(responsenull||response.timeout){mHeartbeatMissCount;if(mHeartbeatMissCount3){Rlog.e(TAG,Modem heartbeat lost, triggering SSR);requestModemSSR();}}else{mHeartbeatMissCount0;}});}voidonModemCrashDetected(intreason){switch(reason){caseMODEM_ERR_WATCHDOG:logCrashReason(Watchdog timeout);break;caseMODEM_ERR_ASSERT:logCrashReason(Assert failure);break;caseMODEM_ERR_EXCEPTION:logCrashReason(Exception/Abort);break;}notifyModemDown();}}4.2 Crash Dump 收集# Modem crash dump 存储路径/data/vendor/ramdump/ modem_crash_dump_YYYYMMDD_HHMMSS/ md_SS_dump.bin# Modem subsystem dumpmd_DATARAM.bin# Data RAMmd_MSGRAM.bin# Message RAMmd_DDRCS0.bin# DDR contentcrash_info.txt# Crash summary# Crash info 示例:# Crash reason: Watchdog timeout# Task: NAS_TASK (Sub1)# PC: 0x8E4F2100# LR: 0x8E4F20A8# Call stack:# nas_emm_process_tau_timeout()# nas_emm_timer_handler()# qurt_timer_isr()4.3 Modem Log (Mini-dump 模式)# 配置 Modem mini-dump轻量级不影响恢复时间# Mini-dump 仅收集关键信息不做全量 RAM dump# 使能 mini-dumpadb shell setprop[厂商私有属性]1# 查看 crash 历史adb shellls/data/vendor/ramdump/# 解析 crash 原因需要 Qualcomm 工具# 使用 QCrashAnalyzer 或 T32 加载 dump 文件5. SSR恢复优化5.1 快速恢复策略SSR 恢复优化技术Warm Reset(热重启)不清除 Modem SRAM 中的关键状态恢复后可直接使用历史注册信息节省 ~2s 的完整初始化时间Early QMI(提前 QMI)Modem 启动完成前就开始 QMI 通道建立并行执行: Modem 初始化 QMI handshake节省 ~500msFast Re-Registration(快速重注册)使用 GUTI (而非 IMSI) 进行 Attach网络侧保留 UE 上下文 (T3412 未超时)跳过 Authentication, 直接 TAU节省 ~1-2sParallel Recovery(并行恢复)双卡注册并行启动 (交错方式)IMS 注册不等待数据完全恢复节省 ~2-3s总优化效果: 恢复时间从 10-15s 降至 5-8s。5.2 防止频繁SSRif (ssr_count_in_1_hour 3) { // 频繁 SSR可能是系统性问题 escalate_to_full_reset(); // 或者进入降级模式 enter_degraded_mode(); } 降级模式策略 - 禁用一些 DSDS 高级特性 - 增大 tune-away 间隔减少竞态 - 切换到单卡模式如果问题持续 - 收集详细 dump 用于后续分析6. 实践指南6.1 监控 SSR 事件# 监听 SSR 事件实时adb logcat|grep-iEssr|modem.*restart|subsystem.*restart# 查看 SSR 历史adb shelldmesg|grep-isubsystem# 典型输出# [12345.678] subsystem-restart: Subsystem modem crashed# [12345.689] subsystem-restart: Modem restart begin# [12349.123] subsystem-restart: Modem restart complete# 查看 SSR 次数统计adb shellcat/sys/class/remoteproc/remoteproc0/crash_count# kernel wakeup 中的 SSR 相关adb shellcat/sys/kernel/debug/wakeup_sources|grepmodem6.2 手动触发 SSR (测试用)# 警告仅用于开发测试环境# 方法1通过sysfs触发adb shellecho restart /sys/class/remoteproc/remoteproc0/state# 方法2通过广播部分平台adb shell am broadcast-acom.qualcomm.action.MODEM_RESTART# 方法3通过diag命令需要QxDM# 发送Modem restart command# 触发后观察# 1. logcat中的SSR日志# 2. 双卡注册恢复时间# 3. 数据连接恢复时间# 4. IMS注册恢复时间6.3 SSR 恢复测试矩阵SSR 恢复验证用例:测试场景操作验证点空闲态SSR双卡待机时触发双卡均恢复注册 ( 10s)数据传输中SSR下载时触发数据自动恢复断点续传生效VoLTE通话中SSR通话时触发通话中断网络恢复 ( 10s)DDS Switch中SSR切换过程触发DDS状态正确恢复IMS注册中SSRREGISTER进行时触发IMS最终注册成功连续SSR10s内触发2次不进入无限重启循环频繁SSR1h内 3 次系统降级/报警/全重启6.4 Crash 分析工具链Modem Crash 分析工具链 1. QCrashAnalyzer高通 - 加载 crash dump - 自动定位 crash 点 - 显示 call stack 2. T32 (Lauterbach TRACE32) - 加载 ELF dump - 源码级调试 - 查看 Modem 任务状态 3. QxDM事前日志 - 抓取 crash 前的 QMI/NAS/RF 日志 - 分析 crash 前的异常序列 - 定位竞态条件的时序 4. ramdump_parser (Linux 工具) - 解析 ramdump 文件结构 - 提取关键信息task list, memory map7. 预防性措施7.1 Modem 侧防护// 关键任务的超时保护voidnas_process_with_timeout(nas_sub_t sub,nas_msg_t*msg){timer_t guard_timerstart_timer(NAS_PROC_TIMEOUT_MS);// 执行 NAS 处理nas_result_t resultnas_process_message(sub,msg);if(timer_expired(guard_timer)){// 超时但未 crash主动清理状态nas_cleanup_state_transaction(sub);LOG_WARN(NAS process timeout on Sub%d, cleaned up,sub);// 避免积累导致后续 crash}stop_timer(guard_timer);}// 双卡 RF 调度的死锁预防voidrf_request_with_deadlock_prevention(rf_sub_t sub,rf_req_t*req){if(!try_acquire_rf_lock(sub,RF_LOCK_TIMEOUT_MS)){// 无法获取 RF 锁可能有死锁风险LOG_ERROR(RF lock timeout, Sub%d, forcing release,sub);force_release_rf_all();// 强制释放所有 RF 锁// 重新调度rf_reschedule_request(sub,req);}}7.2 AP 侧防护// Telephony Framework 的 SSR 防护classPhoneGlobals{// SSR 频率监控privatestaticfinalintMAX_SSR_IN_PERIOD3;privatestaticfinallongSSR_MONITOR_PERIOD_MS3600000;// 1 hourprivateListLongmSsrTimestampsnewArrayList();voidonModemSSR(){longnowSystemClock.elapsedRealtime();mSsrTimestamps.add(now);// 清理过期记录mSsrTimestamps.removeIf(t-now-tSSR_MONITOR_PERIOD_MS);if(mSsrTimestamps.size()MAX_SSR_IN_PERIOD){// 频繁SSR上报问题reportFrequentSSR();// 考虑降级到单卡模式if(shouldFallbackToSingleSim()){switchToSingleSimMode();}}}}8. 总结本文全面分析了DSDS场景下的异常处理和恢复机制DSDS增加了Modem异常的概率竞态条件、时序约束等SSR机制允许Modem单独重启而不影响AP双卡SSR恢复需要额外协调DDS状态、双注册、IMS等通过快速恢复策略可将恢复时间控制在5-10秒预防性措施超时保护、死锁预防可降低crash频率下一篇从DSDS到DSDA高通双卡方案的演进与5G时代展望
系列文章目录本文是“骁龙移动平台双卡双待DSDS的技术内幕”系列的第九篇分析双卡场景下Modem异常崩溃的检测、恢复和对双卡业务的影响。1. 为什么DSDS更容易触发Modem异常1.1 DSDS增加的异常风险┌─────────────────────────────────────────────────────┐ │ DSDS 场景下的额外 Modem 压力 │ │ │ │ 1. 状态复杂度翻倍 │ │ - 双 NAS 状态机并发运行 │ │ - 双 IMS 注册维护 │ │ - 双路 Data Bearer 管理 │ │ │ │ 2. 时序约束更严格 │ │ - Tune-away 时间窗口精确到 ms 级 │ │ - RF 切换必须在 HARQ deadline 内完成 │ │ - IMS keepalive 超时可能引发异常恢复 │ │ │ │ 3. 竞态条件增多 │ │ - 两个 Sub 同时请求 RF │ │ - DDS Switch 与 来电同时发生 │ │ - TAU/LAU 与 data transfer 并发 │ │ │ │ 4. 内存/处理器压力 │ │ - Modem DSP 需要同时处理两份协议栈 │ │ - 缓冲区管理更复杂 │ │ - Cache 压力增大 │ └─────────────────────────────────────────────────────┘1.2 常见 Modem Crash 原因 (DSDS 相关)类别具体原因频率竞态条件RF 调度死锁两 Sub 互等资源中状态异常NAS 状态机进入不合法状态中超时Tune-away 超时导致 watchdog低-中内存Modem heap 溢出双栈占用低信令异常网络侧发送不合规消息低硬件RF PLL 锁频失败累积极低2. SSR (Sub-System Restart) 机制2.1 SSR 基本概念┌─────────────────────────────────────────────────────┐ │ SSR 架构概述 │ │ │ │ 传统处理: Modem crash → 整机重启 (用户体验极差) │ │ │ │ SSR 处理: Modem crash → 仅重启 Modem 子系统 │ │ AP/Android 继续运行 │ │ 用户感知: 短暂无网络 → 自动恢复 │ │ │ │ ┌─────────────────────────────────────────────┐ │ │ │ Application Processor (AP) │ │ │ │ ┌────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ │ │ Android│ │ Framework│ │ 其他进程 │ │ │ │ │ │ Apps │ │ │ │ (继续运行) │ │ │ │ │ └────────┘ └──────────┘ └──────────────┘ │ │ │ └───────────────────┬─────────────────────────┘ │ │ │ (通信中断后重建) │ │ ┌───────────────────▼─────────────────────────┐ │ │ │ Modem Processor (BP) ← 被重启 │ │ │ │ ┌────────┐ ┌──────┐ ┌──────────────────┐ │ │ │ │ │ NAS │ │ CM │ │ RF / L1 │ │ │ │ │ │(重新初始化)│ │ │ (重新校准) │ │ │ │ │ └────────┘ └──────┘ └──────────────────┘ │ │ │ └──────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────┘2.2 SSR 触发条件// Modem 侧错误检测机制// 1. Watchdog Timeout// Modem DSP 看门狗超时任务未在预期时间内完成if(modem_task_elapsedWATCHDOG_TIMEOUT_MS){trigger_ssr(SSR_REASON_WATCHDOG);}// 2. Fatal Error (Assert)// 代码中的断言失败ASSERT(nas_state!INVALID_STATE);// - trigger_ssr(SSR_REASON_ASSERT);// 3. Exception (异常中断)// Data abort, undefined instruction 等// - Hardware interrupt - SSR handler// 4. AP 侧检测到通信异常// QMI 心跳超时if(qmi_heartbeat_lost_countMAX_HEARTBEAT_MISS){request_modem_ssr();// AP 主动触发 Modem 重启}2.3 SSR 恢复流程SSR 恢复时序 (DSDS 场景) T0ms: Modem crash detected T10ms: Modem watchdog fires, 通知 AP T50ms: AP 收到 SSR 通知 ├── RIL[0] 收到 MODEM_DOWN 事件 ├── RIL[1] 收到 MODEM_DOWN 事件 ├── Phone[0] 进入 OUT_OF_SERVICE └── Phone[1] 进入 OUT_OF_SERVICE T100ms: Modem重启开始 ├── Modem firmware 重新加载 ├── Modem 初始化 └── QMI 通道重建 T2000ms: Modem重启完成QMI连接恢复 ├── RIL[0] 检测到 MODEM_UP ├── RIL[1] 检测到 MODEM_UP ├── 重新初始化双 QMI Client └── 发送 QMI Bind Subscription T3000ms: 网络注册恢复 ├── Sub0: 使用 RPLMN 快速注册 └── Sub1: 使用 RPLMN 快速注册 T5000ms: IMS重新注册 ├── Sub0 IMS PDN 重建 SIP REGISTER └── Sub1 IMS PDN 重建 SIP REGISTER T8000ms: 业务完全恢复 ├── 数据连接恢复 ├── VoLTE 能力恢复 └── 用户可正常使用 总恢复时间~5-10秒用户感知无网络3. DSDS对SSR恢复的额外影响3.1 双卡恢复的协调单卡SSR恢复 Modem重启 → 单卡注册 → 数据恢复 → IMS注册 时间5-8秒 双卡SSR恢复更复杂 Modem重启 → 双QMI重建 → DDS卡优先注册 → 非DDS卡注册 → 双IMS重注册 → 业务恢复 时间8-15秒 额外考虑 DDS 状态恢复需要确保默认数据卡配置正确 通话恢复如果 SSR 发生在通话中通话会断开 IMS 注册超时网络侧可能已经注销 UE需要完整注册 Bearer 重建所有 EPS Bearer 需要重新建立3.2 通话中 SSR 的处理场景: Sub0 VoLTE 通话中发生 Modem SSR ┌─────────────────────────────────────────────────┐ │ 影响: │ │ ├── 当前 VoLTE 通话立即中断 │ │ ├── 对端听到提示音 │ │ ├── Sub1 待机状态丢失 │ │ └── 用户体验: 突然掉线 │ │ │ │ 恢复策略: │ │ ├── AP 通知用户通话已断开 │ │ ├── 保存通话记录 (时长、号码) │ │ ├── Modem 恢复后优先恢复 IMS │ │ ├── 如果 SSR 恢复很快 (3s), 尝试自动回拨 │ │ │ (部分 OEM 实现, 非标准行为) │ │ └── 否则通知用户手动重拨 │ └─────────────────────────────────────────────────┘3.3 DDS Switch 过程中的 SSR场景正在执行 DDS Switch 时 Modem crash 风险DDS 状态不确定 可能 Sub0 已断开但 Sub1 未连上 Modem 侧 DDS 标记与 AP 侧不一致 恢复后可能出现数据卡配置错误 处理 1. Modem 恢复后AP 重新下发 DDS 配置 「DDS 切换请求」DSD 服务 2. 如果 Modem 恢复后默认 DDS ! AP 期望 强制执行 DDS Switch 到 AP 期望的卡 3. 数据连接恢复按新 DDS 状态执行4. 错误检测与上报4.1 AP 侧错误检测// RIL 层的 Modem 状态监控classRIL{// Modem 通信心跳检测privatestaticfinalintHEARTBEAT_INTERVAL_MS5000;privateintmHeartbeatMissCount0;voidcheckModemAlive(){sendQmiHeartbeat(response-{if(responsenull||response.timeout){mHeartbeatMissCount;if(mHeartbeatMissCount3){Rlog.e(TAG,Modem heartbeat lost, triggering SSR);requestModemSSR();}}else{mHeartbeatMissCount0;}});}voidonModemCrashDetected(intreason){switch(reason){caseMODEM_ERR_WATCHDOG:logCrashReason(Watchdog timeout);break;caseMODEM_ERR_ASSERT:logCrashReason(Assert failure);break;caseMODEM_ERR_EXCEPTION:logCrashReason(Exception/Abort);break;}notifyModemDown();}}4.2 Crash Dump 收集# Modem crash dump 存储路径/data/vendor/ramdump/ modem_crash_dump_YYYYMMDD_HHMMSS/ md_SS_dump.bin# Modem subsystem dumpmd_DATARAM.bin# Data RAMmd_MSGRAM.bin# Message RAMmd_DDRCS0.bin# DDR contentcrash_info.txt# Crash summary# Crash info 示例:# Crash reason: Watchdog timeout# Task: NAS_TASK (Sub1)# PC: 0x8E4F2100# LR: 0x8E4F20A8# Call stack:# nas_emm_process_tau_timeout()# nas_emm_timer_handler()# qurt_timer_isr()4.3 Modem Log (Mini-dump 模式)# 配置 Modem mini-dump轻量级不影响恢复时间# Mini-dump 仅收集关键信息不做全量 RAM dump# 使能 mini-dumpadb shell setprop[厂商私有属性]1# 查看 crash 历史adb shellls/data/vendor/ramdump/# 解析 crash 原因需要 Qualcomm 工具# 使用 QCrashAnalyzer 或 T32 加载 dump 文件5. SSR恢复优化5.1 快速恢复策略SSR 恢复优化技术Warm Reset(热重启)不清除 Modem SRAM 中的关键状态恢复后可直接使用历史注册信息节省 ~2s 的完整初始化时间Early QMI(提前 QMI)Modem 启动完成前就开始 QMI 通道建立并行执行: Modem 初始化 QMI handshake节省 ~500msFast Re-Registration(快速重注册)使用 GUTI (而非 IMSI) 进行 Attach网络侧保留 UE 上下文 (T3412 未超时)跳过 Authentication, 直接 TAU节省 ~1-2sParallel Recovery(并行恢复)双卡注册并行启动 (交错方式)IMS 注册不等待数据完全恢复节省 ~2-3s总优化效果: 恢复时间从 10-15s 降至 5-8s。5.2 防止频繁SSRif (ssr_count_in_1_hour 3) { // 频繁 SSR可能是系统性问题 escalate_to_full_reset(); // 或者进入降级模式 enter_degraded_mode(); } 降级模式策略 - 禁用一些 DSDS 高级特性 - 增大 tune-away 间隔减少竞态 - 切换到单卡模式如果问题持续 - 收集详细 dump 用于后续分析6. 实践指南6.1 监控 SSR 事件# 监听 SSR 事件实时adb logcat|grep-iEssr|modem.*restart|subsystem.*restart# 查看 SSR 历史adb shelldmesg|grep-isubsystem# 典型输出# [12345.678] subsystem-restart: Subsystem modem crashed# [12345.689] subsystem-restart: Modem restart begin# [12349.123] subsystem-restart: Modem restart complete# 查看 SSR 次数统计adb shellcat/sys/class/remoteproc/remoteproc0/crash_count# kernel wakeup 中的 SSR 相关adb shellcat/sys/kernel/debug/wakeup_sources|grepmodem6.2 手动触发 SSR (测试用)# 警告仅用于开发测试环境# 方法1通过sysfs触发adb shellecho restart /sys/class/remoteproc/remoteproc0/state# 方法2通过广播部分平台adb shell am broadcast-acom.qualcomm.action.MODEM_RESTART# 方法3通过diag命令需要QxDM# 发送Modem restart command# 触发后观察# 1. logcat中的SSR日志# 2. 双卡注册恢复时间# 3. 数据连接恢复时间# 4. IMS注册恢复时间6.3 SSR 恢复测试矩阵SSR 恢复验证用例:测试场景操作验证点空闲态SSR双卡待机时触发双卡均恢复注册 ( 10s)数据传输中SSR下载时触发数据自动恢复断点续传生效VoLTE通话中SSR通话时触发通话中断网络恢复 ( 10s)DDS Switch中SSR切换过程触发DDS状态正确恢复IMS注册中SSRREGISTER进行时触发IMS最终注册成功连续SSR10s内触发2次不进入无限重启循环频繁SSR1h内 3 次系统降级/报警/全重启6.4 Crash 分析工具链Modem Crash 分析工具链 1. QCrashAnalyzer高通 - 加载 crash dump - 自动定位 crash 点 - 显示 call stack 2. T32 (Lauterbach TRACE32) - 加载 ELF dump - 源码级调试 - 查看 Modem 任务状态 3. QxDM事前日志 - 抓取 crash 前的 QMI/NAS/RF 日志 - 分析 crash 前的异常序列 - 定位竞态条件的时序 4. ramdump_parser (Linux 工具) - 解析 ramdump 文件结构 - 提取关键信息task list, memory map7. 预防性措施7.1 Modem 侧防护// 关键任务的超时保护voidnas_process_with_timeout(nas_sub_t sub,nas_msg_t*msg){timer_t guard_timerstart_timer(NAS_PROC_TIMEOUT_MS);// 执行 NAS 处理nas_result_t resultnas_process_message(sub,msg);if(timer_expired(guard_timer)){// 超时但未 crash主动清理状态nas_cleanup_state_transaction(sub);LOG_WARN(NAS process timeout on Sub%d, cleaned up,sub);// 避免积累导致后续 crash}stop_timer(guard_timer);}// 双卡 RF 调度的死锁预防voidrf_request_with_deadlock_prevention(rf_sub_t sub,rf_req_t*req){if(!try_acquire_rf_lock(sub,RF_LOCK_TIMEOUT_MS)){// 无法获取 RF 锁可能有死锁风险LOG_ERROR(RF lock timeout, Sub%d, forcing release,sub);force_release_rf_all();// 强制释放所有 RF 锁// 重新调度rf_reschedule_request(sub,req);}}7.2 AP 侧防护// Telephony Framework 的 SSR 防护classPhoneGlobals{// SSR 频率监控privatestaticfinalintMAX_SSR_IN_PERIOD3;privatestaticfinallongSSR_MONITOR_PERIOD_MS3600000;// 1 hourprivateListLongmSsrTimestampsnewArrayList();voidonModemSSR(){longnowSystemClock.elapsedRealtime();mSsrTimestamps.add(now);// 清理过期记录mSsrTimestamps.removeIf(t-now-tSSR_MONITOR_PERIOD_MS);if(mSsrTimestamps.size()MAX_SSR_IN_PERIOD){// 频繁SSR上报问题reportFrequentSSR();// 考虑降级到单卡模式if(shouldFallbackToSingleSim()){switchToSingleSimMode();}}}}8. 总结本文全面分析了DSDS场景下的异常处理和恢复机制DSDS增加了Modem异常的概率竞态条件、时序约束等SSR机制允许Modem单独重启而不影响AP双卡SSR恢复需要额外协调DDS状态、双注册、IMS等通过快速恢复策略可将恢复时间控制在5-10秒预防性措施超时保护、死锁预防可降低crash频率下一篇从DSDS到DSDA高通双卡方案的演进与5G时代展望
双梁正问题 【 torch 实战】（Python代码实现）)
