[参考译文] TDA4VH-Q1：内核严重错误 — 未同步：异步监测器中断- Wave5 驱动程序

您好、  

您使用的是哪个 HLOS SDK 版本？ 您是否会发现这种情况发生在特定用例中？ 我还没有注意到启动解码器管道时出现的内核错误。

谢谢、
Sarabesh S.

您好、

我目前使用的是 6.15.8 Linux 内核。  当我使用 v4l2h264dec 插件启动单个 gstreamer 解码流水线时、便会发生错误。  panic 似乎总是出现在  wave5_dec_clr_disp_flag () 中。  我一直在解码实时 h264 视频流。  今天,我从 MP4 文件中获取了视频,恐慌发生在同一个点上。 恐慌发生在与 wave5_VPU_dec_start_streaming () 非常接近的地方,但我不确定如何隔离异步错误的来源。

谢谢、

Jeff

您能否共享 gstreamer 流水线？

谢谢、
Sarabesh S.

尊敬的 Sarabesh：

下面是每次诱导 Serror 的流水线。  当执行 wave5_dec_clr_disp_flag () 时、堆栈跟踪总是指示遇到问题。  我已经建立了一个调试内核,并使用 KGDB 在 wave5_dec_clr_disp_flag () 中触发断点。  当 I 步进代码时、SError 会立即触发。  我想读取 0xE000ED28 处的 CFSR 寄存器、但地址无效（我认为存在多个内核）。  不确定用于诊断故障原因的后续步骤...

注意1美元 只是 MP4 文件的路径。

/opt/GStreamer/bin/gst-launch-1.0
filesrc location=${1}\
！ qtdemux name=DEMUX.VIDEO_0 \
！ h264parse config-interval=0 \
！ v4l2h264dec capture-IO-mode=4 \
！ 视频转换\
！ 视频！ 视频/x-raw、max-rate=30/1 \
！ 队列\
！ rtpvrawpay \
！ 'application/x-rtp、media=（字符串）video、encoding-name=（字符串）raw '\
！ udpsink host=127.0.0.1 端口=5000 sync=false async=false

再次感谢、
Jeff

尊敬的 Jeff：  

感谢您提供的信息。 我会回顾一下、然后返回给您。  

此致、
Sarabesh S.

谢谢 Sarabesh。  

我做了一些更多的挖掘。  我看到 ESR 为 0x00000000bf000000。  这将解码为具有 IDS=1 的镜像。  Arm A 曲线架构参考手册指示在这种情况下已定义 ESR_EL1[23：0]来实现。  我不知道在哪里可以找到针对 ISS=24'b0 的具体实施定义。  请告诉我您找到了什么。  我卡住了。

谢谢、Jeff。

谢谢 Jeff、  

目前正在与团队讨论。 我很快就会跟进。

此致、
Sarabesh S.

尊敬的 Sarabesh：

与团队讨论后、您是否有任何更新？ 这是一个高度优先的问题、非常感谢您的指导。

此致、

Luke

您好 Luke、  

您是否完全能够在 TI EVM 上重现此问题？

您好：

请您分享一下输入流。 我将尝试使用最新的 SDK 在我的设置上复制此内容。  

谢谢您、
Sarabesh S.

你（们）好  附件是上述流水线中使用的源视频。  请注意、流水线正在使用 v6.12.17 Linux 内核。  当我们过渡到 v6.15.8 内核时、我们开始看到问题。  Wave5 编解码器驱动程序需要 70MB 的 CMA 内存分配。  为支持此分配、将 CONFIG_ARK_FORCE_MAX_ORDER 内核参数设置为 15（假设页面大小为 4K）。

谢谢、
Jeff

e2e.ti.com/.../Big_5F00_Buck_5F00_Bunny_5F00_720_5F00_10s_5F00_30MB.mp4

您好 Jeffrey、  

感谢您的参与。 以下几个澄清问题：

1. 您是否已经在  6.12 内核中设置了带有 CONFIG_ARK_FORCE_MAX_ORDER=15 的 CMA 分配、或者是否为新设置？ 默认值是什么？
2. 您能否确认在 u-boot CMA 参数中传递了什么 CMA？  
3. 如果您更改 u-boot cmdline 中的 CMA、内核崩溃是否会发生、如下所示：
   https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j784s4/11_01_00_03/exports/docs/linux/How_to_Guides/Target/How_To_Carve_Out_ cma.html#how-to-configure-the-cma-size

谢谢您、
Sarabesh S.

尊敬的 Sarabesh：

我一直在与 Jeffrey 合作解决这个问题、现在我们有更多详细信息。

首先、上行 6.12.17 内核和 6.16.9 内核（或 6.15.7 内核，两者的行为相同）上都需要 CMA 配置和 CONFIG_ARCH_FORCE_MAX_ORDER=15。  如果没有这一点、流水线甚至无法启动。  因此、这只是我们现在开始这项工作的一项要求。

第二,我能够根据上面给出的 gstreamer 命令行和之前连接的 Big Buck Bunny 视频 Jeff 设置一个最小的再制作程序。   我能够  在 TI J784S4XEVM 板上重现崩溃、因此目前我正在对它进行测试。

我将 J784S4XEVM 板上主线内核版本的问题从 6.12.17 分流到 6.16.9、并发现导致问题的提交结果为：

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit?id=2092b3833487e5ce138f4303f98e46ba0f87f1d0

请注意、这进入了 6.13 内核系列、但目前正在由 TI 的 SDK 版本 11 向后移植到 TI 的 6.12 供应商内核中。

我还了解到,如果我只是在 6.16.9 主线内核中恢复这个提交,问题就会消失。

我发现这个补丁系列刚刚由编解码器 IP 块供应商发布：

https://lore.kernel.org/linux-media/20250922055255.116-1-jackson.lee@chipsnmedia.com/

我尝试应用这些修补程序、问题仍然存在。  因此、在这一点上、我认为这是一个上游仍然存在的问题。

为了使这个崩溃发生,我们已经了解到,在播放大降压兔子视频时打开调试会导致崩溃可靠地发生。  这在我们的生产意图使用中是不必要的,这是有趣的。  根据导致这种情况的原因（添加了编解码器暂停支持）、我假设这可能与推送到编解码器的工作负载有关。

下面是我用于重现此问题的命令：

export GST_DEBUG=6
gst-launch-1.0 \
    filesrc location=Big_Buck_Bunny_720_10s_30MB.mp4 \
    ! qtdemux name=demux demux.video_0 \
    ! h264parse config-interval=0 \
    ! v4l2h264dec capture-io-mode=4 output-io-mode=4 \
    ! videoconvert \
    ! videorate ! video/x-raw,max-rate=30/1 \
    ! queue \
    ! rtpvrawpay \
    ! 'application/x-rtp, media=(string)video, encoding-name=(string)RAW' \
    ! udpsink host=127.0.0.1 port=5000 sync=false async=false

我计划使用最新标记的 TI 供应商内核尝试此测试、看看是否在那里进行、但我的猜测是这样。

当我有这些详细信息时、我将向此 TT 添加更新。

您好：  

很高兴您能够 在 11.01.14 标签中找到修复程序。 我同意这与运行时 pm 支持提交有关。 分辨率可能是由于增加了 autospend_delay、因此 VPU 在仍有帧正在使用时不会断电。 我注意到、 您共享的 CNM 补丁系列将延迟设置为 500ms、但在我们的树中、您可以看到它设置为 5000ms (https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/media/platform/chips-media/wave5/wave5-vpu.c?h=11.01.14&id=b4249050fcdb302f50ca047f4606dc8025cf27bb) gst_debug=6 可能使情况减慢到足以使自动暂停在操作过程中触发、从而导致崩溃。

此致、
Sarabesh S.