[参考译文] AM5716：CAN 通信问题

您好、Tony、

我将查看此问题、但请注意、此 SDK 不再受标准支持。

其次、如果对基本 SDK 默认设置有任何更改、您能否分享一下？

此致、

Josue

客户进一步调试进度：

Ccccording to 'No buffer space available ' return from write()、 当 c_can_do_tx () 检测到的 CAN 消息对象已从 CAN_INTPND 寄存器中满时、将导致 write() 触发 ENOBUFS 错误。

根据内核日志：net CAN0：c_can_hw_raminit_wait_SYSCON：超时、这是因为当 c_can_hw_raminit_wait_SYSCON () 复位 时、从寄存器 CTRL_core_control_IO_2 的 RAM 会超时超过 1ms。 RAM 似乎未按预期复位。  

当 CAN 通信过程中存在严重的噪音/干扰时、很容易触发此问题。 似乎 CAN RAM 中的消息对象未及时发送、或者 CAN RAM 无法初始化。  

希望它能帮助您进行调查。

您好 Josue、

客户确认他们没有基于默认 SDK CAN 驱动程序器件进行任何修改。 请帮助分析上述 Tony 的调查结果。 如果您在从 SDK9 到最新 SDK 的 CAN 驱动程序中找到任何相对已知的修复方法、也请分享给我们。

谢谢、

Kevin

Tony、Kevin、

是否已在 TI EVM 上重新创建此属性？

请分享娱乐程序。

-Josue

Kevin、Tony、

我会看看我是否可以尝试一些在我这边的实验。 这似乎是一种比赛条件、需要动手测试才能决定该怎么做。

我也应该免责声明、我不是 CAN 专家、这是我第一次查看这个 CAN_C 驱动器、因此我不会立即修复。 我需要时间分析并了解这些误差、因为这看起来像是一种级联情况、很难确定根本原因。

我确实找到了下面的补丁,这可能与这个竞争条件在新版本的内核 — 感谢   Kevin Peng 的指针: https://lore.kernel.org/all/20250520114332.8961-3-axfo@kvaser.com/

客户可以尝试对其进行反向移植、看看它是否有帮助。

此致、

Josue

Josue,

URL 中的驱动程序似乎不适用于 c_can_main 驱动程序、它特定于 Kvaser PCI 接口 CANFD 控制器。

--- a/drivers/net/can/kvaser_pciefd.c
++ b/drivers/net/can/kvaser_pciefd.c

您好团队：

除了错误报告之外、我没有找到此上游的任何相关修补程序。 这似乎是 在 c_can_start_xmit() 和之间产生的竞态条件 c_can_do_tx() 、可能会导致“echo_skb 占用“错误并在高负载条件下丢弃数据包。  

我能够在本地重现其中的一些问题、因此我将在下周尝试一些修复。 请记住、明天是美国的假日、因此我将在星期一之前不会有空。

e2e.ti.com/.../can_5F00_stress_5F00_test_5F00_20260402_5F00_182434.log

我需要做更多的跟进和测试。

-Josue

您好 Josue、

希望您有一个美好的假期。 请问您是如何重现这些问题的？ 是否有任何更新？

谢谢、

Kevin

尊敬的 Kevin：

我不得不专注于其他问题、但我可以在本周晚些时候给您一些更新。 我能够在 AM5718 IDK 中的 CAN 模块上使用内部环回模式并使用环路来模拟高负载情况、重现一些问题。

在一些帮助下、我创建了以下脚本： /cfs-file/__key/communityserver-discussions-components-files/791/can_5F00_stress_5F00_test.sh

请处理客户期望、因为不再支持此 SDK、因此我的帮助将在时间允许的情况下受到限制。 我仍在努力理解如何解决这一问题。

其次、这不是 TI 驱动程序、因此它受我们的 SDK 开源免责声明的约束。

请参阅 software-dl.ti.com/.../、Overview_Technical_Support

-Josue

您好 Kevin、  

我仍在研究这个问题。

作为中间步骤、您能否要求客户运行应力测试并共享输出？

此致、

-Josue

Kevin、

由于我无法重现客户遇到的一些错误、我不确定这将会有多大帮助：

下面是一个补丁、用于帮助降低我找到的一些 echo_skb 竞态条件。 也许这会有所帮助。

e2e.ti.com/.../echo_5F00_skb_5F00_race.patch

CAN 测试的结果也可能有所帮助。 您能否与客户确认他们已对 CAN 总线终端、接地/信号完整性问题进行过任何验证？ 屏蔽电缆？  

-Josue

您好 Kevin、

我将看一看并尝试在本周结束前做出回应。  

您能否与客户确认他们对 CAN 总线终端、接地/信号完整性问题进行了任何验证？ 屏蔽电缆？

您能跟进这个问题吗？

-Josue

您好 Josue、

压力测试期间的 CAN 端口使用 RJ45 以太网电缆直接连接、CANH、CANL 和 GND 均正确连接。 由于这是在办公环境中进行的、因此未应用屏蔽、但当实际部署在终端客户现场时、可能会产生严重干扰。 PCAN 数据包捕获执行了 1 小时、其中应力测试脚本显示总线负载峰值约为 12%、未观察到错误帧。

您还想让 客户测试什么？

谢谢、

Kevin

TI 电路板是否仍不再生产？

-Josue

您好 Josue、

客户没有 EVM/IDK。

#1。 从您共享的日志中删除。 在测试 1 期间、它报告了写入：没有可用的缓冲区空间、但 ENOBUFS 错误计数为 0、它们是否相关？   

#2. “客户 有两个相同的 AM5716 器件直接连接到 CAN“、是否需要将两个 CAN 节点直接连接 120 Ω 端接？ 您有两个 IDK 要测试吗？

#3.  echo_skb_race.patch 的测试结果是什么

#4. 客户在相同测试环境下使用 SDK6.03 进行了 80 分钟以上的测试、未报告错误。

[01:20:09] Interface statistics:
2: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can <LOOPBACK> state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
          bitrate 1000000 sample-point 0.750
          tq 50 prop-seg 7 phase-seg1 7 phase-seg2 5 sjw 1
          c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
          clock 20000000
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0
    RX: bytes  packets  errors  dropped overrun mcast
    5702444    734096   0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    5702444    734096   0       0       0       0

=== ERROR SUMMARY ===
echo_skb occupied errors: 0
0
RAMINIT timeout errors: 0
0
ENOBUFS errors: 0
0
IRQ 'nobody cared' errors: 0
0
====================

尊敬的 Tony：

#4 使用 SDK 6.03 进行非常有趣的详细测试。 您没有指定、但我假设这是通过 RT-Linux SDK 完成的、正确吗？

6.03 测试基准可能是最好的方法。

#1 — 有点期待。 压力测试有目的地发送的消息多于可能处理的消息、因此这些打印件是可以预期的。 驱动程序最终会跟上、因此 ENOBUFS 为 0。 是的、相关性不高。

#2 — 是的，我认为这是规范的一部分：

我有两个 IDK。 但我不确定可以进行等效测试、因为我们没有相同的电路板。

#3 我的 echo_skb 错误减少了 50%

我将向您介绍本周在星期五上可以进行的测试。

-Josue

今晚实验的更新、客户增加了 dmesg 容量、并在 SDK9.3 上使用和不使用补丁重新执行压力测试：

每次执行测试时、他们都会提前断电和通电。

不带补丁程序试用版 1：

[01:05:09] Interface statistics:
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can <LOOPBACK> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
          bitrate 1000000 sample-point 0.750
          tq 50 prop-seg 7 phase-seg1 7 phase-seg2 5 sjw 1
          c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
          clock 20000000
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0
    RX: bytes  packets  errors  dropped overrun mcast
    7505483    972924   0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    7505483    972924   0       31      0       0

=== ERROR SUMMARY ===
echo_skb occupied errors: 1
RAMINIT timeout errors: 844
ENOBUFS errors: 0
0
IRQ 'nobody cared' errors: 0
0
====================

不带补丁程序试用版 2：

[01:11:03] Interface statistics:
2: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can <LOOPBACK> state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
          bitrate 1000000 sample-point 0.750
          tq 50 prop-seg 7 phase-seg1 7 phase-seg2 5 sjw 1
          c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
          clock 20000000
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0
    RX: bytes  packets  errors  dropped overrun mcast
    8278449    1074104  0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    8278452    1074104  0       51      0       0

=== ERROR SUMMARY ===
echo_skb occupied errors: 2
RAMINIT timeout errors: 969
ENOBUFS errors: 0
0
IRQ 'nobody cared' errors: 0
0
====================

不带补丁程序试用版 3：

[00:51:46] Interface statistics:
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can <LOOPBACK> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
          bitrate 1000000 sample-point 0.750
          tq 50 prop-seg 7 phase-seg1 7 phase-seg2 5 sjw 1
          c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
          clock 20000000
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0
    RX: bytes  packets  errors  dropped overrun mcast
    6216893    805561   0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    6216902    805561   0       62      0       0

=== ERROR SUMMARY ===
echo_skb occupied errors: 2
RAMINIT timeout errors: 707
ENOBUFS errors: 0
0
IRQ 'nobody cared' errors: 0
0
====================

带补丁程序试用版 1.

[01:09:21] Interface statistics:
2: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can <LOOPBACK> state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
          bitrate 1000000 sample-point 0.750
          tq 50 prop-seg 7 phase-seg1 7 phase-seg2 5 sjw 1
          c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
          clock 20000000
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0
    RX: bytes  packets  errors  dropped overrun mcast
    7445644    965551   0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    7445703    965552   0       217     0       0

=== ERROR SUMMARY ===
echo_skb occupied errors: 7
RAMINIT timeout errors: 1067
ENOBUFS errors: 0
0
IRQ 'nobody cared' errors: 0
0
====================

使用修补程序试用版 2.

[00:46:49] Interface statistics:
2: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can <LOOPBACK> state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
          bitrate 1000000 sample-point 0.750
          tq 50 prop-seg 7 phase-seg1 7 phase-seg2 5 sjw 1
          c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
          clock 20000000
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0
    RX: bytes  packets  errors  dropped overrun mcast
    5686463    736945   0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    5686469    736945   0       93      0       0

=== ERROR SUMMARY ===
echo_skb occupied errors: 3
RAMINIT timeout errors: 839
ENOBUFS errors: 0
0
IRQ 'nobody cared' errors: 0
0
====================

使用修补程序试用版 3.

第三次测试：
[00:45:46] Interface statistics:
2: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can <LOOPBACK> state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
          bitrate 1000000 sample-point 0.750
          tq 50 prop-seg 7 phase-seg1 7 phase-seg2 5 sjw 1
          c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
          clock 20000000
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0
    RX: bytes  packets  errors  dropped overrun mcast
    5450258    706497   0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    5450262    706497   0       62      0       0

=== ERROR SUMMARY ===
echo_skb occupied errors: 2
RAMINIT timeout errors: 782
ENOBUFS errors: 0
0
IRQ 'nobody cared' errors: 0
0
====================

您可以看到、补丁没有改善以减少 echo_skb 和 RAMINIT 超时错误的错误数

此外、使用补丁有时会导致出现额外的错误、下面的错误在没有补丁的情况下永远不会发生：

[ 1631.765626] net can0: c_can_hw_raminit_wait_syscon: time out
[ 1650.264030] net can0: c_can_hw_raminit_wait_syscon: time out
[ 1655.381667] BUG: scheduling while atomic: irq/91-can0/28397/0x00000002
[ 1655.382162] softirq: huh, entered softirq 2 NET_TX 758c5363 with preempt_count 00000000, exited with ffffffff?
[ 1659.794121] net can0: c_can_hw_raminit_wait_syscon: time out
[ 1663.544073] net can0: c_can_hw_raminit_wait_syscon: time out

谢谢、

Kevin

您好 Kevin、

我现在正在进行一些分析。 我必须考虑采用不同的设置、而不是我所用的测试设置、那就是仅使用 CAN 模块的内部环回模式。

对于我的测试、我的程序如下所示：

1. 在环回模式下设置 CAN  
2. 使用 Sk-echo 补丁进行测试：
   

   [20:57:07] ==========================================
   [20:57:07] TEST 6: Combined Stress Test (All Issues)
   [20:57:07] ==========================================
   [20:57:07] Running combined stress test...
   [20:57:07] Phase 1: High-rate TX...
   [20:57:07] Setting up CAN interface: main_dcan1
   [SUCCESS] CAN interface main_dcan1 ready at 1000000 bps
   [20:57:11] Phase 2: Rapid restart cycles...
   [20:57:12] Phase 3: Concurrent TX waves...
   [20:57:12] Setting up CAN interface: main_dcan1
   [SUCCESS] CAN interface main_dcan1 ready at 1000000 bps
   [20:57:14] Combined stress test complete
   [20:57:14] Checking for errors after: Combined Stress Test
   [WARNING] Found kernel messages:
     [ 2195.215972] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2195.231353] IPv6: ADDRCONF(NETDEV_CHANGE): main_dcan1: link becomes ready
     [ 2329.844268] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2333.437530] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2333.523986] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2333.619506] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2333.706878] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2333.794342] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2333.886627] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2333.973632] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2334.064331] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2334.161407] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2334.258880] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2334.573303] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
     [ 2335.245727] c_can_platform 4ae3c000.can main_dcan1: can_put_echo_skb: BUG! echo_skb 2 is occupied!
   [20:57:14] Interface statistics:
   5: main_dcan1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
       link/can  promiscuity 0 minmtu 0 maxmtu 0
       can <LOOPBACK> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
             bitrate 1000000 sample-point 0.750
             tq 50 prop-seg 7 phase-seg1 7 phase-seg2 5 sjw 1 brp 1
             c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp_inc 1
             clock 20000000
             re-started bus-errors arbit-lost error-warn error-pass bus-off
             0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platfo
       RX:  bytes packets errors dropped  missed   mcast
             3001     527      0       0       0       0
       TX:  bytes packets errors dropped carrier collsns
             3008     527      0       0       0       0
   
   === ERROR SUMMARY ===
   echo_skb occupied errors: 1
   RAMINIT timeout errors: 0
   0
   ENOBUFS errors: 0
   0
   IRQ 'nobody cared' errors: 0
   0
   ====================
   
   [ERROR] Invalid choice:
   [ERROR] Invalid choice:
   [20:58:40] Cleaning up background processes...
   [ERROR] Invalid choice:
   [20:58:44] Cleaning up background processes...
   [20:58:45] Exiting...

如您所见、我仍然没有看到任何 RAMINIT 错误、并且只有一个 echo_skb。 我也没有看到任何内核挂起、但我没有长时间承受过压力。

我没有看到您提到的内核挂起、我打开/关闭了 6 次、但没有发生。

我同意客户必须查看从 SDK 6.03 到 SDK 9.3 的更改内容。 我将尝试提供帮助、但再次强调、这是一个开源驱动程序。  

我会让你知道我在我这边找到了什么。 我仍然担心无法重现 RAMINIT 问题。  
明天我将处理此问题、从现在起、我建议恢复我所做的任何修补程序。

-Josue  

您好 Josue、

客户在周末进行了以下测试：

1：根据 SDK 9.3、客户尝试回滚 CAN 驱动程序并执行连续测试约 17 小时；echo_skb 问题不再出现。 通过重复的 USB 插入和移除来验证“无人关心“IRQ 问题、它也不明显。 这表明它明显比 SDK9.3 更稳定、但 RAMINIT 超时问题仍然频繁发生。

2： 单器件和双器件直接连接的应力测试结果相同；两者都容易重现 RAMINIT 超时问题。

3: 超时问题发生在函数链 c_can_open()->c_can_reset_ram ()->c_can_hw_raminit_syscon(enable) 内 c_can_hw_raminit_syscon(enable) 的第二个调用中（即 enable = true 条件块内）。 尝试将 c_can_hw_raminit_wait_SYSCON () 的超时阈值增加到 5000us 未解决问题。 该问题似乎是由 CTRL_CORE_CONTROL_IO_2 寄存器中的 DCAN1_RAMINIT_DONE 未及时就绪而引起的、并且 TRM 手册中没有关于此操作所需时间的详细说明。

在 SDK9.3 上用于回滚 CAN 驱动程序的差分代码如下：

diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 643507777..f508e6a6d 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -197,6 +197,7 @@ struct c_can_priv {
    unsigned int msg_obj_tx_first;
    unsigned int msg_obj_tx_last;
    u32 msg_obj_rx_mask;
+   atomic_t tx_active;
    atomic_t sie_pending;
    unsigned long tx_dir;
    int last_status;
@@ -211,7 +212,6 @@ struct c_can_priv {
    struct c_can_raminit raminit_sys;   /* RAMINIT via syscon regmap */
    void (*raminit)(const struct c_can_priv *priv, bool enable);
    u32 comm_rcv_high;
-   raw_spinlock_t echo_skb_lock;   /* Protects echo_skb array access for RT kernel */
 };
 
 struct net_device *alloc_c_can_dev(int msg_obj_num);
diff --git a/drivers/net/can/c_can/c_can_main.c b/drivers/net/can/c_can/c_can_main.c
index 46f09c92a..68f78a9b1 100644
--- a/drivers/net/can/c_can/c_can_main.c
+++ b/drivers/net/can/c_can/c_can_main.c
@@ -454,35 +454,32 @@ static netdev_tx_t c_can_start_xmit(struct sk_buff *skb,
 {
    struct can_frame *frame = (struct can_frame *)skb->data;
    struct c_can_priv *priv = netdev_priv(dev);
-   struct c_can_tx_ring *tx_ring = &priv->tx;
-   u32 idx, obj, cmd = IF_COMM_TX;
-   unsigned long flags;
+   u32 idx, obj;
 
    if (can_dev_dropped_skb(dev, skb))
        return NETDEV_TX_OK;
+   /*
+    * This is not a FIFO. C/D_CAN sends out the buffers
+    * prioritized. The lowest buffer number wins.
+    */
+   idx = fls(atomic_read(&priv->tx_active));
+   obj = idx + priv->msg_obj_tx_first;
 
-   if (c_can_tx_busy(priv, tx_ring))
-       return NETDEV_TX_BUSY;
-
-   idx = c_can_get_tx_head(tx_ring);
-   tx_ring->head++;
-   if (c_can_get_tx_free(priv, tx_ring) == 0)
+   /* If this is the last buffer, stop the xmit queue */
+   if (idx == priv->msg_obj_tx_num - 1)
        netif_stop_queue(dev);
 
-   if (idx < c_can_get_tx_tail(tx_ring))
-       cmd &= ~IF_COMM_TXRQST; /* Cache the message */
-
    /* Store the message in the interface so we can call
     * can_put_echo_skb(). We must do this before we enable
     * transmit as we might race against do_tx().
     */
    c_can_setup_tx_object(dev, IF_TX, frame, idx);
-   /* Minimal lock hold time - only during echo_skb write */
-   raw_spin_lock_irqsave(&priv->echo_skb_lock, flags);
-   can_put_echo_skb(skb, dev, idx, 0);
-   raw_spin_unlock_irqrestore(&priv->echo_skb_lock, flags);
-   obj = idx + priv->msg_obj_tx_first;
-   c_can_object_put(dev, IF_TX, obj, cmd);
+   can_put_echo_skb(skb, dev, idx, frame->len);
+
+   /* Update the active bits */
+   atomic_add((1 << idx), &priv->tx_active);
+   /* Start transmission */
+   c_can_object_put(dev, IF_TX, obj, IF_COMM_TX);
 
    return NETDEV_TX_OK;
 }
@@ -593,7 +590,6 @@ static int c_can_software_reset(struct net_device *dev)
 static int c_can_chip_config(struct net_device *dev)
 {
    struct c_can_priv *priv = netdev_priv(dev);
-   struct c_can_tx_ring *tx_ring = &priv->tx;
    int err;
 
    err = c_can_software_reset(dev);
@@ -625,8 +621,7 @@ static int c_can_chip_config(struct net_device *dev)
    priv->write_reg(priv, C_CAN_STS_REG, LEC_UNUSED);
 
    /* Clear all internal status */
-   tx_ring->head = 0;
-   tx_ring->tail = 0;
+   atomic_set(&priv->tx_active, 0);
    priv->tx_dir = 0;
 
    /* set bittiming params */
@@ -724,15 +719,14 @@ static int c_can_get_berr_counter(const struct net_device *dev,
 static void c_can_do_tx(struct net_device *dev)
 {
    struct c_can_priv *priv = netdev_priv(dev);
-   struct c_can_tx_ring *tx_ring = &priv->tx;
    struct net_device_stats *stats = &dev->stats;
-   u32 idx, obj, pkts = 0, bytes = 0, pend;
-   u8 tail;
+   u32 idx, obj, pkts = 0, bytes = 0, pend, clr;
 
    if (priv->msg_obj_tx_last > 32)
        pend = priv->read_reg32(priv, C_CAN_INTPND3_REG);
    else
        pend = priv->read_reg(priv, C_CAN_INTPND2_REG);
+   clr = pend;
 
    while ((idx = ffs(pend))) {
        idx--;
@@ -744,37 +738,19 @@ static void c_can_do_tx(struct net_device *dev)
         * NAPI. We are not transmitting.
         */
        c_can_inval_tx_object(dev, IF_NAPI, obj);
-       /* Minimal lock hold time - only during echo_skb read */
-       raw_spin_lock(&priv->echo_skb_lock);
        bytes += can_get_echo_skb(dev, idx, NULL);
-       raw_spin_unlock(&priv->echo_skb_lock);
        pkts++;
    }
 
-   if (!pkts)
-       return;
+   /* Clear the bits in the tx_active mask */
+   atomic_sub(clr, &priv->tx_active);
 
-   tx_ring->tail += pkts;
-   if (c_can_get_tx_free(priv, tx_ring)) {
-       /* Make sure that anybody stopping the queue after
-        * this sees the new tx_ring->tail.
-        */
-       smp_mb();
-       netif_wake_queue(priv->dev);
-   }
-
-   stats->tx_bytes += bytes;
-   stats->tx_packets += pkts;
-
-   tail = c_can_get_tx_tail(tx_ring);
-   if (priv->type == BOSCH_D_CAN && tail == 0) {
-       u8 head = c_can_get_tx_head(tx_ring);
+   if (clr & (1 << (priv->msg_obj_tx_num - 1)))
+       netif_wake_queue(dev);
 
-       /* Start transmission for all cached messages */
-       for (idx = tail; idx < head; idx++) {
-           obj = idx + priv->msg_obj_tx_first;
-           c_can_object_put(dev, IF_NAPI, obj, IF_COMM_TXRQST);
-       }
+   if (pkts) {
+       stats->tx_bytes += bytes;
+       stats->tx_packets += pkts;
    }
 }
 
@@ -833,9 +809,7 @@ static int c_can_read_objects(struct net_device *dev, struct c_can_priv *priv,
        ctrl = priv->read_reg(priv, C_CAN_IFACE(MSGCTRL_REG, IF_NAPI));
 
        if (ctrl & IF_MCONT_MSGLST) {
-           int n;
-
-           n = c_can_handle_lost_msg_obj(dev, IF_NAPI, obj, ctrl);
+           int n = c_can_handle_lost_msg_obj(dev, IF_NAPI, obj, ctrl);
 
            pkts += n;
            quota -= n;
@@ -1231,7 +1205,6 @@ struct net_device *alloc_c_can_dev(int msg_obj_num)
        return NULL;
 
    priv = netdev_priv(dev);
-   raw_spin_lock_init(&priv->echo_skb_lock);
    priv->msg_obj_num = msg_obj_num;
    priv->msg_obj_rx_num = msg_obj_num - msg_obj_tx_num;
    priv->msg_obj_rx_first = 1;
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index 86e95e9d6..56fa46805 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -489,8 +489,8 @@ static struct platform_driver c_can_plat_driver = {
    },
    .probe = c_can_plat_probe,
    .remove = c_can_plat_remove,
-   .suspend = c_can_suspend,
-   .resume = c_can_resume,
+   .suspend = NULL,
+   .resume = NULL,
    .id_table = c_can_id_table,
 };

您能否帮助分析客户的回滚代码并在您身边进行测试？ 似乎只  需要根据此解决方案来解决剩余的 RAMINIT 超时。

谢谢、

Kevin

另外、在客户端重新共享应力测试脚本的 diff 代码（客户进行了以下微小修改，主要是为了调整 CAN 中断在/proc/interrupts 中的位置并缩短睡眠时间以提高测试效率）、请问这里的 diff 代码是否合理、只是要确保 RAMINIT 超时现象的差异不是由于应力测试本身造成的。

diff --git a/can_stress_test.sh b/can_stress_test.sh
index 2f69080..1e22e13 100644
--- a/can_stress_test.sh
+++ b/can_stress_test.sh
@@ -4,15 +4,15 @@
 # Tests for Issues: ENOBUFS, RAMINIT timeout, echo_skb race, IRQ problems
 #
 # Usage: ./can_stress_test.sh [interface]
-# Example: ./can_stress_test.sh main_dcan1
+# Example: ./can_stress_test.sh can0
 #
 
 set -e
 
 # Configuration
-CAN_IFACE="${1:-main_dcan1}"
+CAN_IFACE="${1:-can0}"
 BITRATE=1000000
-LOG_FILE="/tmp/can_stress_test_$(date +%Y%m%d_%H%M%S).log"
+LOG_FILE="/home/root/can/log/can_stress_test_$(date +%Y%m%d_%H%M%S).log"
 
 # Colors for output
 RED='\033[0;31m'
@@ -61,7 +61,7 @@ check_errors() {
     log "Checking for errors after: $test_name"
 
     # Get current dmesg
-    local errors=$(dmesg | tail -50 | grep -iE "can|echo_skb|raminit|irq.*154|ENOBUFS|nobody cared|time out|occupied" | tail -20)
+    local errors=$(dmesg | tail -50 | grep -iE "can|echo_skb|raminit|irq.*91|ENOBUFS|nobody cared|time out|occupied" | tail -20)
 
     if [ -n "$errors" ]; then
         log_warning "Found kernel messages:"
@@ -201,9 +201,9 @@ test_sustained_load() {
     log "Transmitters running... monitoring for 10 seconds"
 
     # Monitor interrupt count
-    local irq_start=$(cat /proc/interrupts | grep 154 | awk '{print $2}')
+    local irq_start=$(cat /proc/interrupts | grep "91:" | awk '{print $2}')
     sleep 10
-    local irq_end=$(cat /proc/interrupts | grep 154 | awk '{print $2}')
+    local irq_end=$(cat /proc/interrupts | grep "91:" | awk '{print $2}')
     local irq_count=$((irq_end - irq_start))
 
     log "IRQ count during test: $irq_count"
@@ -223,7 +223,7 @@ test_irq_stress() {
     log "Starting IRQ monitoring..."
 
     # Get initial IRQ count
-    local irq_before=$(cat /proc/interrupts | grep 154 | awk '{print $2}')
+    local irq_before=$(cat /proc/interrupts | grep "91:" | awk '{print $2}')
 
     log "Launching extreme burst load..."
 
@@ -237,7 +237,7 @@ test_irq_stress() {
     done
 
     # Get final IRQ count
-    local irq_after=$(cat /proc/interrupts | grep 154 | awk '{print $2}')
+    local irq_after=$(cat /proc/interrupts | grep "91:" | awk '{print $2}')
     local irq_delta=$((irq_after - irq_before))
 
     log "IRQ count: $irq_delta interrupts processed"
@@ -312,15 +312,15 @@ run_all_tests() {
     log "=========================================="
 
     test_tx_buffer_exhaustion
-    sleep 2
+    sleep 0.2
     test_raminit_timeout
-    sleep 2
+    sleep 0.2
     test_echo_skb_race
-    sleep 2
+    sleep 0.2
     test_sustained_load
-    sleep 2
+    sleep 0.2
     test_irq_stress
-    sleep 2
+    sleep 0.2
     test_combined_stress
 
     log "=========================================="
@@ -344,13 +344,13 @@ show_status() {
     ip -s -d link show "$CAN_IFACE"
     echo ""
     log "Interrupt Statistics:"
-    cat /proc/interrupts | grep -E "CPU|154"
+    cat /proc/interrupts | grep -E "CPU|91:"
 }
 
 show_dmesg_errors() {
     echo ""
     log "Recent CAN-related kernel messages:"
-    dmesg | tail -50 | grep -iE "can|echo_skb|raminit|irq.*154|ENOBUFS|nobody cared|time out|occupied" || echo "No errors found"
+    dmesg | tail -50 | grep -iE "can|echo_skb|raminit|irq.*91|ENOBUFS|nobody cared|time out|occupied" || echo "No errors found"
 }
 
 # Trap Ctrl+C
@@ -375,8 +375,9 @@ done
 # Interactive mode if no arguments
 if [ $# -lt 2 ]; then
     while true; do
-        show_menu
-        read -p "Select test (0-9): " choice
+        # show_menu
+        # read -p "Select test (0-9): " choice
+        choice=7
         echo ""
 
         case $choice in
@@ -398,7 +399,7 @@ if [ $# -lt 2 ]; then
         esac
 
         echo ""
-        read -p "Press Enter to continue..."
+        # read -p "Press Enter to continue..."
     done
 fi

您好 Kevin、

请检查此处的 diff 代码是否合理

更改是正确和合理的。 我看不出它们有任何问题。 我已经测试了时间变化在我的一边与一致的结果。

您能否帮助分析客户的回滚代码

我很高兴听到我们的距离越来越近、客户击败我完成了回滚（我从星期五开始，打算今天结束）。 这些变化看起来不错、我个人有一个问题：

diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index 86e95e9d6..56fa46805 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -489,8 +489,8 @@ static struct platform_driver c_can_plat_driver = {
},
.probe = c_can_plat_probe,
.remove = c_can_plat_remove,
- .suspend = c_can_suspend,
- .resume = c_can_resume,
+ .suspend = NULL,
+ .resume = NULL,
.id_table = c_can_id_table,
};

为什么.suspend 和.resume 设置为空？

此 RAMINIT 问题是一个棘手的问题、它可能与 CAN 驱动程序无关、更可能与其他子系统相关（因为在中的代码相同） c_can_platform.c c_can_hw_raminit_wait_syscon(), etc。  

为什么它在 4.19 中工作、而在 6.1 中不工作？

我这边的另一个曲线焊球是 RAMINIT 问题对于我来说是不可重复的。 （需要注意的是，我仅使用一个 EVM 在环回模式下进行了测试）。

鉴于客户对寄存器的调查以及我一直在研究的一些信息（链接）、RT Linux 似乎发生了一些变化、使得 Spinlock 在 RT Linux 中早产化、因此需要使用 raw_spinlock 来确保像此寄存器读取这样的原子低级操作。 您是否可以让客户尝试以下补丁程序：

e2e.ti.com/.../use_5F00_raw_5F00_spinlock.patch

regmap alrady 的驱动程序具有原始 spinlock 选项、因此我们将其添加以采用该路径。 希望这有所帮助。

我测试了我的增补程序以及上面的客户增补程序、以下是我的结果：

Select test (0-9): 6

[22:37:51] ==========================================
[22:37:51] TEST 6: Combined Stress Test (All Issues)
[22:37:51] ==========================================
[22:37:51] Running combined stress test...
[22:37:51] Phase 1: High-rate TX...
[22:37:51] Setting up CAN interface: main_dcan1
[  107.513183] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[  107.527252] IPv6: ADDRCONF(NETDEV_CHANGE): main_dcan1: link becomes ready
[SUCCESS] CAN interface main_dcan1 ready at 1000000 bps
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
[22:37:55] Phase 2: Rapid restart cycles...
[  111.176269] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[  111.276306] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[  111.376312] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[  111.476287] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[  111.585449] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[  111.694946] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[  111.799316] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[  111.916351] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[  112.028656] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[  112.136474] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[22:37:56] Phase 3: Concurrent TX waves...
[22:37:56] Setting up CAN interface: main_dcan1
[  112.479553] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[SUCCESS] CAN interface main_dcan1 ready at 1000000 bps
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
write: No buffer space available
[22:37:58] Combined stress test complete
[22:37:58] Checking for errors after: Combined Stress Test
[WARNING] Found kernel messages:
  [  107.513183] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
  [  107.527252] IPv6: ADDRCONF(NETDEV_CHANGE): main_dcan1: link becomes ready
  [  111.176269] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
  [  111.276306] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
  [  111.376312] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
  [  111.476287] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
  [  111.585449] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
  [  111.694946] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
  [  111.799316] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
  [  111.916351] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
  [  112.028656] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
  [  112.136474] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
  [  112.479553] c_can_platform 4ae3c000.can main_dcan1: setting BTR=4d00 BRPE=0000
[22:37:58] Interface statistics:
5: main_dcan1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0
    can <LOOPBACK> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
          bitrate 1000000 sample-point 0.750
          tq 50 prop-seg 7 phase-seg1 7 phase-seg2 5 sjw 1 brp 1
          c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp_inc 1
          clock 20000000
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 parentbus platform pa
    RX:  bytes packets errors dropped  missed   mcast
         13818    2392      0       0       0       0
    TX:  bytes packets errors dropped carrier collsns
         13818    2392      0       0       0       0

=== ERROR SUMMARY ===
echo_skb occupied errors: 0
0
RAMINIT timeout errors: 0
0
ENOBUFS errors: 0
0
IRQ 'nobody cared' errors: 0
0
====================

此致、

Josue

您好 Josue、

 .suspend 和 .resume 字段已设置为 NULL 避免勘误手册中提到的 DCAN 初始化序列问题。 由于客户不考虑节能场景、并将以最大功耗实现最高性能运行、因此这两个字段设置为 NULL 按照未配置 CONFIG_PM 的逻辑进行操作。

客户已测试 USE_RAW_SPINLOCK.patch、但超时问题没有任何改进。

客户现在计划首先将此 CAN 驱动程序回滚代码应用到其实际应用产品、作为一种解决方法、但他们仍需要我们继续调查此超时问题、并尽快向他们提供合理的解释和解决方案。

谢谢、

Kevin

您好 Kevin、

客户现在计划首先将此 CAN 驱动程序回滚代码应用于其实际应用程序产品、作为解决方法、但他们仍然需要我们继续调查此超时问题、并尽快向他们提供合理的解释和解决方案。

如上所述、

我这边的另一个曲线焊球是 RAMINIT 问题对我来说是不可重复的。

这将是很困难的、因为我们无法在本地重现此问题。 客户能否在此处链接的代码中添加打印件、以确保代码采用 raw_spinlock 路径？

regmap

上文您提到、即使在环回模式下未连接到另一块板的情况下、客户也会看到这些 RAMINIT 问题、这是正确的吗？

我与回滚更改保持一致、它们是有意义的。 我有另一个补丁、在我假设正在发生的情况实际发生时可能会很有用。 让我知道客户发现的有关 raw_spinlock 补丁的内容。

否则、他们可以尝试以下补丁：

e2e.ti.com/.../jiffies.patch

我 µs 抢占实际上使该函数中的计数器不会实际为 1 μ s、因此进行一次迭代需要更长时间、从而造成超时。 该补丁使其“挂钟“依赖于计数器、因此占先不会产生 RAMINIT 超时。

LMK。

-Josue

Ping 更新。

您好 Josue、

感谢您的提问。 我刚刚联系了客户、他们的反馈是使用我们之前讨论的回滚代码、它已经解决了大多数 CAN 问题、只剩下 RAMINIT 超时。 因此、与他们当前正在处理的其他 AM57 问题相比、这并不紧急、他们将尽力解决其他 AM57 问题、然后尽快解决此 RAMINIT 超时问题。

我将继续与客户跟踪他们的进度、让他们测试上面分享的补丁并返回。

谢谢、

Kevin