This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] TDA4VH-Q1:CPSW9G 本机驱动器遇到 NETDEV 看门狗问题

Guru**** 2696685 points
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1580429/tda4vh-q1-cpsw9g-native-drive-encounters-the-netdev-watchdog-issue

器件型号: TDA4VH-Q1
Thread 中讨论的其他器件: TDA4VH

您好 TI 专家:

 

  我们将 SDK11.0 和 CPSW9G 本机驱动器用于我们的项目、网络拓扑、如下所示:

 

  SERDES1-Lane2-SMGII1 -->100Base-T1 (TI-DP83TC814S)
  SERDES1-Lane2-SMGII2 -->100Base-T1 (TI-DP83TC814S)
  SERDES2-LANE0-SMGII5 -->固定链路 (MCU-RH850)
  SERDES2-LANE1-SMGII6 --> 1000Base-Tx (88EA1512)
  SERDES2-Lane2-SMGII7 --> 1000Base-T1 (TI-DP83TG720S)
  SERDES2-LANE3-SMGII8 --> 1000Base-T1 (TI-DP83TG720S)
 
  我们的定制电路板运行数小时后、出现以下错误。所有网络都崩溃

  [80277.984921] am65-cpsw-Nuss c000000.Ethernet eth2:netdev 看门狗:CPU:7:传输队列 1 超时 21046528 ms
  [80277.995365] am65-cpsw-Nuss c000000.Ethernet eth2:TxQ:1 DRV_XOFF:0 TMO:21046536 dql_avail:–337 free_desc:506
  [80278.005326] am65-cpsw-Nuss c000000.Ethernet eth5:netdev 看门狗:CPU:7:传输队列 1 超时 79978008 ms
  [80278.015647] am65-cpsw-Nuss c000000.Ethernet eth5:TxQ:1 DRV_XOFF:0 TMO:79978016 dql_avail:–337 free_desc:506
  [80278.748916] am65-cpsw-Nuss c000000.Ethernet eth0:netdev 看门狗:CPU:6:传输队列 1 超时 79978752 ms
  [80278.759289] am65-cpsw-Nuss c000000.Ethernet eth0:TxQ:1 DRV_XOFF:0 TMO:79978760 dql_avail:–337 free_desc:506
  [80278.769238] am65-cpsw-Nuss c000000.Ethernet eth4:netdev 看门狗:CPU:6:传输队列 1 超时 79978772 ms
  [80278.779604] am65-cpsw-Nuss c000000.Ethernet eth4:TxQ:1 DRV_XOFF:0 TMO:79978780 dql_avail:–337 free_desc:506
  [80278.789546] am65-cpsw-Nuss c000000.Ethernet eth1:netdev 看门狗:CPU:6:发送队列 1 超时 79978792 ms
  [80278.799879] am65-cpsw-Nuss c000000.Ethernet eth1:TxQ:1 DRV_XOFF:0 TMO:79978800 dql_avail:–337 free_desc:506
  [80283.872923] am65-cpsw-Nuss c000000.Ethernet eth5:netdev 看门狗:CPU:7:传输队列 1 超时 7983876 ms
  [80283.872921] am65-cpsw-Nuss c000000.Ethernet eth1:netdev 看门狗:CPU:6:传输队列 1 超时 7983876 ms
  [80283.872945] am65-cpsw-Nuss c000000.Ethernet eth1:TxQ:1 DRV_XOFF:0 TMO:799883876 dql_avail:–337 free_desc:506
  [80283.883273] am65-cpsw-Nuss c000000.Ethernet eth5:TxQ:1 DRV_XOFF:0 TMO:799883884 dql_avail:–337 free_desc:506
  [80283.893546] am65-cpsw-Nuss c000000.Ethernet eth4:netdev 看门狗:CPU:6:发送队列 1 超时 799883896 ms
  [80283.903351] am65-cpsw-Nuss c000000.Ethernet eth2:netdev 看门狗:CPU:7:传输队列 1 超时 21052444 ms
  [80283.913199] am65-cpsw-nuss c000000.Ethernet eth4:TxQ:1 DRV_XOFF:0 TMO:799883916 dql_avail:–337 free_desc:506
  [80283.923451] am65-cpsw-Nuss c000000.Ethernet eth2:TxQ:1 DRV_XOFF:0 TMO:21052464 dql_avail:–337 free_desc:506
  [80283.933710] am65-cpsw-Nuss c000000.Ethernet eth0:netdev 看门狗:CPU:6:传输队列 1 超时 79983936 ms
  [80283.963747] am65-cpsw-Nuss c000000.Ethernet eth0:TxQ:1 DRV_XOFF:0 TMO:799883964 dql_avail:–337 free_desc:506
  [80288.736920] am65-cpsw-Nuss c000000.Ethernet eth2:netdev 看门狗:CPU:7:传输队列 1 超时 21057280 ms
 
故障期间的相关信息如下所示:
 
我们的 cpsw9g 配置脚本如下所示:
#!/bin/sh

/usr/sbin/devlink dev param set platform/c000000.ethernet name switch_mode value true cmode runtime

/sbin/ip link add name br0 type bridge
/sbin/ip link set dev br0 type bridge ageing_time 1000

/sbin/ip link set dev eth0 up
/sbin/ip link set dev eth1 up
/sbin/ip link set dev eth2 up
/sbin/ip link set dev eth3 up
/sbin/ip link set dev eth4 up
/sbin/ip link set dev eth5 up

/sbin/ip link set dev eth0 master br0
/sbin/ip link set dev eth1 master br0
/sbin/ip link set dev eth2 master br0
/sbin/ip link set dev eth3 master br0
/sbin/ip link set dev eth4 master br0
/sbin/ip link set dev eth5 master br0
/sbin/ip link set dev br0 type bridge vlan_filtering 1
# /sbin/ip link set dev br0 type bridge stp_state 1
/usr/sbin/bridge vlan add dev br0 vid 1 self
/usr/sbin/bridge vlan add dev br0 vid 1 pvid untagged self


/sbin/ip link set dev br0 address 00:00:00:00:00:09

/sbin/ip link set dev br0 up

/sbin/ip addr add 192.168.0.2/24 dev br0

#/sbin/ip addr del 192.168.0.2/24 dev br0
#/sbin/ip addr add 192.168.0.4/24 dev br0
#!/bin/sh

# Configuration parameters
BRIDGE="br0"
MAX_WAIT=100      # Maximum wait time in seconds
CHECK_INTERVAL=1  # Check interval in seconds

# Wait for /usr/sbin/bridge to be up
echo "Waiting for /usr/sbin/bridge $BRIDGE to be up..."
wait_time=0
while [ $wait_time -lt $MAX_WAIT ]; do
    if /sbin/ip link show dev "$BRIDGE" 2>/dev/null | grep -q "state UP"; then
        /sbin/ip link set dev br0 address 02:04:00:00:03:02
        echo "Bridge $BRIDGE is up,reconfig bridge mac addr ok"
        break
    fi
    
    if [ $wait_time -ge $MAX_WAIT ]; then
        echo "Error: Timeout waiting for /usr/sbin/bridge $BRIDGE to be up"
        exit 1
    fi
    
    sleep $CHECK_INTERVAL
    wait_time=$((wait_time + CHECK_INTERVAL))
done

for vlan_id in "17" "49" "65" "257"; do
    for interface in "eth0" "eth1" "eth3" "eth4" "eth5"; do
        /usr/sbin/bridge vlan add dev "${interface}" vid "${vlan_id} master"
        /usr/sbin/bridge vlan set dev "${interface}" vid "${vlan_id}" priority 0
    done
done

for vlan_id in "33" "45" "100" "101" "110"; do
    vlan_iface="${BRIDGE}.${vlan_id}"
    ip_address="172.16.${vlan_id}.99/24"
    /sbin/ip link add link "${BRIDGE}" name "$vlan_iface" type vlan id "$vlan_id"
    /sbin/ip link set dev "$vlan_iface" up
    /sbin/ip addr add "$ip_address" dev "$vlan_iface" 2>/dev/null
    /usr/sbin/bridge vlan add dev "${BRIDGE}" vid "${vlan_id}" self
    if [ "${vlan_id}" = "45" ]; then
        /usr/sbin/bridge vlan set dev "${BRIDGE}" vid "${vlan_id}" priority 1 self
    else
        /usr/sbin/bridge vlan set dev "${BRIDGE}" vid "${vlan_id}" priority 0 self
    fi
    
    for interface in "eth0" "eth1" "eth3" "eth4" "eth5"; do
        /usr/sbin/bridge vlan add dev "${interface}" vid "${vlan_id} master"
        if [ "${vlan_id}" = "45" ]; then
            /usr/sbin/bridge vlan set dev "${interface}" vid "${vlan_id}" priority 1
        else
            /usr/sbin/bridge vlan set dev "${interface}" vid "${vlan_id}" priority 0
        fi
    done
done
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    其他信息:

    1.我们使用 SBL 引导模式

    2. 将 br0 设备的 IP 地址设置为 192.168.0.2。 在同一网段中使用四个具有不同 IP 地址的外部网卡在主板上执行连续 ping 测试。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 TI 专家:

    此问题非常紧急、请尽快让客户知道调试此问题所需的条件。

    谢谢、

    Kevin

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、

    设备的平均 CPU 利用率是多少? 出现问题时会看到什么。

    您可以 在后台运行命令“ mpstat -P all 1“以获取利用率。

    设备运行时的网络流量是怎样的? 您也可以运行以下脚本来了解它:

    #!/bin/bash
    
    # Interval in seconds between measurements
    INTERVAL=1
    
    # Function to get RX and TX bytes for all interfaces
    get_all_stats() {
        for iface in /sys/class/net/*; do
            IFACE_NAME=$(basename "$iface")
            RX_BYTES=$(cat "$iface/statistics/rx_bytes")
            TX_BYTES=$(cat "$iface/statistics/tx_bytes")
            echo "$IFACE_NAME $RX_BYTES $TX_BYTES"
        done
    }
    
    # Function to convert bytes/sec to human-readable format
    human_readable() {
        local BYTES=$1
        if [ "$BYTES" -lt 1024 ]; then
            echo "${BYTES} B/s"
        elif [ "$BYTES" -lt $((1024 * 1024)) ]; then
            echo "$(bc <<< "scale=2; $BYTES/1024") KB/s"
        else
            echo "$(bc <<< "scale=2; $BYTES/(1024*1024)") MB/s"
        fi
    }
    
    # Initial stats
    declare -A RX1 TX1
    while read -r IFACE RX TX; do
        RX1["$IFACE"]=$RX
        TX1["$IFACE"]=$TX
    done < <(get_all_stats)
    
    echo "Monitoring network usage for all interfaces:"
    echo "Press Ctrl+C to stop."
    
    # Infinite loop to calculate differences
    while true; do
        sleep $INTERVAL
    
        declare -A RX2 TX2
        while read -r IFACE RX TX; do
            RX2["$IFACE"]=$RX
            TX2["$IFACE"]=$TX
        done < <(get_all_stats)
    
        echo "----------------------------------------"
        for IFACE in "${!RX1[@]}"; do
            RX_DIFF=$((RX2["$IFACE"] - RX1["$IFACE"]))
            TX_DIFF=$((TX2["$IFACE"] - TX1["$IFACE"]))
            RX_HUMAN=$(human_readable $RX_DIFF)
            TX_HUMAN=$(human_readable $TX_DIFF)
            echo "Interface: $IFACE | RX: $RX_DIFF bytes/sec ($RX_HUMAN) | TX: $TX_DIFF bytes/sec ($TX_HUMAN)"
            RX1["$IFACE"]=${RX2["$IFACE"]}
            TX1["$IFACE"]=${TX2["$IFACE"]}
        done
    done
    

    这不是设置问题。

    如果网络由于某些情况而长时间无法发送通信、通常会发生这种情况。 这将导致 netdev 看门狗关闭并挂起所有 TX 队列。

    此致、
    Tanmay

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、

    此外、是否还有其他 DMA 主要应用在其他内核上运行?

    此致、
    Tanmay

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    由于我们仅执行 ping 操作、因此网络流量非常低。 日志如下所示

    e2e.ti.com/.../net_5F00_bc.log

    由于我们目前处于 PreDV 阶段、因此我们开发了一个应用程序来提高 CPU 利用率。 因此、在测试过程中、CPU 利用率相对较高。 我们还怀疑 CPU 的加载是问题的原因,因此移除应力测试程序后,问题仍然存在。 CPU 状态如下:

    e2e.ti.com/.../mpstat_5F00_no_5F00_stress.log

    e2e.ti.com/.../mpstat_5F00_with_5F00_stress.log

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我们在外部连接了多个摄像头。 在 MCU2_0 上、我们运行了与摄像头相关的服务。 在此过程中使用了 DMA。 此外、A72 内核使用 SPI 与 RH850(速率为 10M)在芯片之间进行通信。 它还使用了 DMA 和 openvx 演示程序。 DMA 可能被间接使用。 我们自己添加了 SPI。 器件树如下所示:

    &main_spi0 {
    	status="okay";
    	spi-slave;
    	pinctrl-names = "default";
    	pinctrl-0 = <&main_spi0_pins_default>;
    	ti,spi-num-cs = <1>;
    	dmas = <&main_udmap 0xc600>, <&main_udmap 0x4600>; /* drivers/dma/ti/k3-psil-j784s4.c */
    	dma-names = "tx0", "rx0";
    	slave@0 {
    		spi-max-frequency = <10000000>;
    		reg = <0>;
    		compatible = "linux,spidev";
    		spidev_gpio_rdy{
    			spi-rdy-gpios = <&main_gpio0 16 GPIO_ACTIVE_HIGH>;
    		};
    	};
    };

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、

    应力版本和未应力版本之间的问题发生时间是否有任何差异? 也就是说、如果在器件承受应力时问题重现得更快、或者问题是相同的、还是随机的?

    我们从外部连接了多个摄像头。 在 MCU2_0 上、我们运行了与摄像头相关的服务

    连接了多少个摄像头? 您是将视觉应用用于摄像头应用还是自定义应用?

    此外、A72 内核使用 SPI 通过 RH850 在芯片之间进行通信、速率为 10M

    这种影响应该不大。

    问题是每次大约同时发生、还是非常随机?

    无论哪种方式、您都要尝试通过将“drivers/net/Ethernet/ti/am65-cpsw-nuss.c"中“中的宏“AM65_CPSW_MAX_TX_DESC"值“值从 500 更改为 1000 来增加 CPSW Tx 队列的 DMA 描述符。

    此致、
    Tanmay

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    - 加载不会使它更有可能发生。 此问题通常在设备运行 24 小时内随机出现。

    -我们连接了七个摄像头。

    - 问题不是在固定的时间发生;相反,它是随机发生的。

    - 好的,谢谢你的建议。 我们将尝试修改 AM65_CPSW_MAX_TX_DESC、并进行测试以查看问题是否改善。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    补充信息:我们使用的是自定义摄像头应用程序。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    最新的发展是、即使我们修改了 AM65_CPSW_MAX_TX_DESC 的值、运行 14 小时后仍然出现问题。 似乎没有改善。您还有其他建议吗?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 TI 专家:我们获得了以下新测试结果。 禁用摄像机相关功能并运行三天测试后、进行了相同的测试、目前一切都正常运行。 您之前提到过 DMA。 如果是由 DMA 引起的问题、您能否提供一些建议、说明如何检查 DMA 通道的使用情况以及如何避免与网络使用的 DMA 发生冲突?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Tanmay、

    客户正在等待我们的建议超过一周、您能否请尽快回复?

    Kevin

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    抱歉、Kevin。 当我尝试添加一些其他信息时、我按下了错误的按钮。 现在、此帖子处于“已解决“状态。 您能帮助我将状态改回吗?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jiance:

    感谢您提供的信息、我们已重新打开它、并将邀请我们的专家尽快提供反馈、谢谢

    Kevin

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、

    我尝试了这个脚本、就像在我的 TDA4VH 上一样、我没有看到错误。

    我现在需要在后台强调 DMA、以便使用 DMA 测试仪模块重建 Linux。 我将在今天晚上之前分享有关此结果的最新信息。

    此外、解决此问题的方法之一是关闭接口再打开。 短期内还可以吗? 我可以提供一个补丁、以便每次点击 netdev_watchdog 时、网络接口都会切换。

    此致、
    Tanmay

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    首先是将网卡卸下然后再备份的解决方案。 问题发生后 (eth3 ),我手动执行它,但它不起作用。 可能是因为应用程序的数据仍在不断发送。 此外、在“up"之后“之后、另一个网卡 (eth2 + eth3) 发出了另一条错误消息。 第二,关于发生恐慌的情况,据我的理解,“下行“操作不会生效,对吧?

    root@adcu-v2:~#[   41.949746] am65-cpsw-nuss c000000.ethernet eth3: NETDEV WATCHDOG: CPU: 5: transmit queue 1 timed out 25592 ms
    [   41.959834] am65-cpsw-nuss c000000.ethernet eth3: txq:1 DRV_XOFF:0 tmo:25600 dql_avail:-24224 free_desc:480
    root@adcu-v2:~#ifconfig eth3 down[   46.813750] am65-cpsw-nuss c000000.ethernet eth3: NETDEV WATCHDOG: CPU: 5: transmit queue 1 timed out 30456 ms
    [   46.823808] am65-cpsw-nuss c000000.ethernet eth3: txq:1 DRV_XOFF:0 tmo:30464 dql_avail:-24224 free_desc:480
    
    [   48.048912] am65-cpsw-nuss c000000.ethernet eth3: Link is Down
    [   48.073884] br0: port 4(eth3) entered disabled state
    root@adcu-v2:~#
    root@adcu-v2:~#
    root@adcu-v2:~#ifconfig eth3 up
    [   52.667898] am65-cpsw-nuss c000000.ethernet eth3: PHY [c000f00.mdio:0e] driver [Marvell 88E1510] (irq=POLL)
    [   52.677833] am65-cpsw-nuss c000000.ethernet eth3: configuring for phy/sgmii link mode
    [   52.685857] am65-cpsw-nuss c000000.ethernet: mode:4 adv:1 
    [   52.691484] am65-cpsw-nuss c000000.ethernet: sgmii ctrl value:1 
    [   52.698541] 8021q: adding VLAN 0 to HW filter on device eth3
    root@adcu-v2:~#
    root@adcu-v2:~#
    root@adcu-v2:~#[   54.749751] am65-cpsw-nuss c000000.ethernet eth2: NETDEV WATCHDOG: CPU: 6: transmit queue 1 timed out 5216 ms
    [   54.759718] am65-cpsw-nuss c000000.ethernet eth2: txq:1 DRV_XOFF:0 tmo:5224 dql_avail:-1514 free_desc:478
    [   55.780433] am65-cpsw-nuss c000000.ethernet eth3: Link is Up - 1Gbps/Full - flow control off
    [   55.780468] br0: port 4(eth3) entered blocking state
    [   55.793922] br0: port 4(eth3) entered forwarding state
    [   59.873744] am65-cpsw-nuss c000000.ethernet eth2: NETDEV WATCHDOG: CPU: 6: transmit queue 1 timed out 10340 ms
    [   59.883819] am65-cpsw-nuss c000000.ethernet eth2: txq:1 DRV_XOFF:0 tmo:10348 dql_avail:-1514 free_desc:478
    
    root@adcu-v2:~#[   64.993747] am65-cpsw-nuss c000000.ethernet eth2: NETDEV WATCHDOG: CPU: 6: transmit queue 1 timed out 15460 ms
    [   65.003813] am65-cpsw-nuss c000000.ethernet eth2: txq:1 DRV_XOFF:0 tmo:15468 dql_avail:-1514 free_desc:478
    [   66.753753] am65-cpsw-nuss c000000.ethernet eth3: NETDEV WATCHDOG: CPU: 7: transmit queue 5 timed out 5460 ms
    [   66.763731] am65-cpsw-nuss c000000.ethernet eth3: txq:5 DRV_XOFF:0 tmo:5468 dql_avail:-3028 free_desc:507
    [   70.877766] am65-cpsw-nuss c000000.ethernet eth2: NETDEV WATCHDOG: CPU: 6: transmit queue 1 timed out 21344 ms
    [   70.887865] am65-cpsw-nuss c000000.ethernet eth2: txq:1 DRV_XOFF:0 tmo:21352 dql_avail:-1514 free_desc:478
    [   71.901751] am65-cpsw-nuss c000000.ethernet eth3: NETDEV WATCHDOG: CPU: 7: transmit queue 5 timed out 10608 ms
    [   71.911824] am65-cpsw-nuss c000000.ethernet eth3: txq:5 DRV_XOFF:0 tmo:10616 dql_avail:-3028 free_desc:507
    ^C
    
    root@adcu-v2:~#[   75.997750] am65-cpsw-nuss c000000.ethernet eth2: NETDEV WATCHDOG: CPU: 6: transmit queue 1 timed out 26464 ms
    [   76.007812] am65-cpsw-nuss c000000.ethernet eth2: txq:1 DRV_XOFF:0 tmo:26472 dql_avail:-1514 free_desc:478
    [   76.765770] am65-cpsw-nuss c000000.ethernet eth3: NETDEV WATCHDOG: CPU: 7: transmit queue 5 timed out 15472 ms
    [   76.775832] am65-cpsw-nuss c000000.ethernet eth3: txq:5 DRV_XOFF:0 tmo:15480 dql_avail:-3028 free_desc:507

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、

    其次、关于发生恐慌的情况、根据我的理解、“向下“操作不会生效、对吧?[/报价]

    是的,我们不知道任何恢复是否会帮助崩溃? 在这种情况下值得一试。 但是、由于向下和向上计数也无法解决问题、因此在问题发生时、似乎我们可能需要移除并初始化 DMA 通道本身。 这样也会重置 dql 并重新启动网络。

    我现在需要在后台强调 DMA、以便使用 DMA 测试仪模块重建 Linux。 我将在今天晚上分享此结果的更新

    在运行应用程序时、我给 10 个 DMA 通道施加了高负载压力、甚至没有发现问题。 简而言之、我无法在 EVM 上重现问题。 你有什么建议可以帮助我解决这个问题吗?

    此致、
    Tanmay

    [/quote]
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    好的。 感谢您进行这些测试。 根据我之前的测试、当我们关闭与摄像头相关的应用程序时、问题就会消失。 因此、我可能怀疑我们修改的内存布局可能存在问题(我们在定制电路板上使用了 8G 内存)。 我们可以要求相关同事查看我们的记忆布局吗? 或者、从您的角度来看、存储器布局是否可能会影响本机以太网驱动程序? 由于不适当的存储器布局、R5F2_0 的 DMA 是否可能被阻止、从而影响 A72 内核的以太网相关 DMA?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Tanmay、

    这可能是导致以太网端崩溃的系统级问题、您能否让客户知道需要从客户端查看哪个内存布局文件

    谢谢、

    Kevin

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Kevin:

    请在此处共享存储器修改内容。 此外、还请告诉我您所做的任何 MSMC 修改。

    我将向我们的专家介绍这一主题、让他们看看。

    此致、
    Tanmay

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、 Tanmay、

    我在周末内核崩溃时分析了堆栈跟踪。 执行 gen_pool_free_owner 的 bitmap_clear_ll 函数时、会检测到存储器位图中的错误、因此会自动触发 BUG_ON。

    191     ATOMIC64_OPS(add, add, I)
       0xffff8000804c6858 <+228>:   62 41 00 91     add     x2, x11, #0x10
       0xffff8000804c685c <+232>:   51 00 80 f9     prfm    pstl1strm, [x2]
       0xffff8000804c6860 <+236>:   40 7c 5f c8     ldxr    x0, [x2]
       0xffff8000804c6864 <+240>:   00 00 15 8b     add     x0, x0, x21
       0xffff8000804c6868 <+244>:   40 7c 01 c8     stxr    w1, x0, [x2]
       0xffff8000804c686c <+248>:   a1 ff ff 35     cbnz    w1, 0xffff8000804c6860 <gen_pool_free_owner+236>
       0xffff8000804c6870 <+252>:   f0 ff ff 17     b       0xffff8000804c6830 <gen_pool_free_owner+188>
    
    lib/genalloc.c:
    505                             BUG_ON(addr + size - 1 > chunk->end_addr);
       0xffff8000804c6874 <+256>:   00 00 21 d4     brk     #0x800
    
    508                             BUG_ON(remain);
       0xffff8000804c6878 <+260>:   00 00 21 d4     brk     #0x800
    
    ./include/linux/rcupdate.h:
    882             __rcu_read_unlock();
       0xffff8000804c687c <+264>:   f5 23 f0 97     bl      0xffff8000800cf850 <__rcu_read_unlock>
    
    --Type <RET> for more, q to quit, c to continue without paging--
    lib/genalloc.c:
    518             BUG();
       0xffff8000804c6880 <+268>:   00 00 21 d4     brk     #0x800

    这是否意味着在当前的 CPSW 网络驱动程序中、当网络数据包发生 DMA 超时时、会出现重复存储器释放的情况、或者是由于堆栈溢出导致位图损坏? Netdev 看门狗和内核崩溃、这两个不同的结果是否都是由 DMA 传输超时引起的?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Tanmay、

    您能否将 Jiance 分享的内存布局转发给相应的专家以供审核?

    顺便说一下、Jiance 在上面发现了这个问题的一个好问题、在您的测试中是否可以手动让 DMA 超时来测试 CPSW 驱动程序中是否有任何重复的存储器版本?

    谢谢、

    Kevin

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Kevin:

    我目前不在办公室、 明天我将在存储器映射中查看。

    此致、
    Gokul  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好 Jiance.Zhang 

    您能否共享生成的 app_mem_map.h 文件和 linker_mem_map.cmd、MPU CONFIG、MCU2_0 内核的链接器文件。

    此致、
    Gokul

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Kevin:

    我已转发更改。

    Jiance 在上述问题上发现了一个好问题、是否可以在您的测试中手动让 DMA 超时来测试 CPSW 驱动程序中是否有任何重复的内存版本?

    你或 Jiance 对我该如何做有任何建议吗? 我更想说的是、我们可以通过 CPSW 驱动程序统计排队的字节和排队的字节。

    错误似乎在队列管理中的某个位置。 我们要分配的字节和要释放的字节可能不匹配。 这与 netdev watchdog 问题打印以及 dql_avail 值为负时的结果一致。

    当发生这种情况时、错误可能只是一个临界情况观察到的问题。

    您能尝试看看下面的补丁是否有问题吗? 每当我们考虑来自 cpsw 的 TX 数据包时、都会添加打印内容。

    e2e.ti.com/.../bql_5F00_prints_5F00_cpsw.diff

    此致、
    Tanmay

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    好的、我将添加这个补丁并进行测试。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jiance:

    存储器映射看起来没有问题、但我有一点困惑、

    C7X_DDR_STACK_MEM 的物理地址未在文件中定义、它与 MCU2_0 IPC addr 冲突、我希望它在 c7x MMU 配置中得到正确处理、或者此地址未在任何位置映射。

    RAT 配置应该执行 2 个 RAT 区域、一个用于 DDR_SHARED_MEM、另一个用于 r5f_heap_addr。 在您共享的代码中 、您仅配置了 r5f_heap_addr、是否在 rat ?中也配置了 DDR_SHARED_MEM。

    此致、
    Gokul

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    文件中未定义 C7X_DDR_STACK_MEM 的物理地址、它与 MCU2_0 IPC addr 冲突、我希望它在 c7x MMU 配置中得到正确处理、或者此地址未在任何位置映射

    是的、由于低端地址短缺、空间的 C7X_DDR_STACK_MEM 段实际上位于高端地址。 我们已经使用自己的内存管理算法为 FreeRTOS 分配任务栈、并已正确执行 MMU 映射。

        retVal = Mmu_map(C7X_DDR_STACK_MEM_ADDR, C7X_1_DDR_STACK_MEM_PHYS_ADDR, C7X_DDR_STACK_MEM_SIZE, &attrs, is_secure); /* ddr            */
        if(retVal == FALSE)
        {
            goto mmu_exit;
        }
    

    ;rat 配置应该执行 2 个 rat 区域、一个用于 DDR_SHARED_MEM、另一个用于 r5f_heap_addr。 在您共享的代码中 、您仅配置了 r5f_heap_addr、是否在 rat 中也配置了 DDR_SHARED_MEM?

    是的、DDR_SHARED_MEM_ADDR 是 SDK 的原始配置、我们尚未将其删除。

        /* Only programming RAT if the physical address is in high mem */
        if (DDR_SHARED_MEM_PHYS_ADDR > 0xFFFFFFFF)
        {
            /* Making the DDR_SHARED_MEM size aligned to 1GB by adding the UBOOT_RELOC_MEM_SIZE.                        */
            /* The UBOOT_RELOC_MEM_SIZE was subtracted from DDR_SHARED_MEM size while creating the memory map for J784S4*/
            /* This was done because the 1GB DDR_SHARED_MEM size was overlapping the UBOOT_RELOC_MEM_ADDR at the end of */
            /* low 2GB memory. For more details on this, please refer to 3.1.1.1.6. Available RAM for image download    */
            /* section in processor-sdk-linux documentation                                                             */
            ddr_mem_rat_prm.size              = DDR_SHARED_MEM_SIZE + UBOOT_RELOC_MEM_SIZE;
            ddr_mem_rat_prm.baseAddress       = DDR_SHARED_MEM_ADDR;
            ddr_mem_rat_prm.translatedAddress = DDR_SHARED_MEM_PHYS_ADDR;
    
            status = appMemAddrTranslate(&ddr_mem_rat_prm);
            APP_ASSERT_SUCCESS(status);
        }

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    对于专门为 R5 内核和 C7 内核分配的存储器、我们已在 DTS 文件中保留了该存储器。 理论上、以太网使用的系统存储器会避开该区域。 因此、我认为 R5 内核和 C7 内核的操作不应错误地修改为以太网分配的存储器。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jiance:

    理论上、以太网使用的系统内存将避免此区域

    是的、但是如果内存处理不当、r5f 应用程序可能会损坏这些区域。 因为它映射到 r5f。 如果 C7x 尝试访问以太网存储器、但未进行映射、则它会异常。

    此致、
    Gokul

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您能更具体地说吗? 以 MCU2_0 为例。 对于当前的存储器布局、尽管 1G 范围内的 DDR_SHARED_MEM 由 RAT 映射、并且还映射了 LOCAL_HEAP、但映射的物理存储器具有 40 位地址、并已在 DTS 中保留。 R5F 只能访问最多 4GB 的空间。 如果 R5F 尝试访问超过此限制的地址、则理论上它只能访问 32 位地址。 我们能否确保在 DTS 文件中保留 4GB 内的所有空间、以便以太网根本不使用 4GB 内的任何空间? 同时、我们能否验证问题是否仍然存在? 如果问题仍然存在、是否表明当前的以太网崩溃与 R 核心的应用无关? 至少、这不应是由于对以太网使用的存储器的越界访问所致。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jiance:

    您能更具体吗?
    但如果内存处理不当、r5f 应用程序很可能会损坏这些区域。 因为它映射到 r5f。 如果 C7x 尝试访问以太网存储器、因为它未映射、则它将进入异常。

    我只是说,如果应用程序直接使用以太网区域的存储器,它仍然能够访问和破坏它,因为以太网存储器映射到 r5f。 我并不是说这种情况发生在你的情况下。

    同时、我们能否验证问题是否仍然存在? 如果问题仍然存在、是否表明当前的以太网崩溃与 R 核心的应用无关? 至少、这不应是由于对以太网使用的内存的越界访问造成的。

    我们能否首先验证 Tanmay Patil 提供的修补程序 、看看您是否能在其中找到任何修补程序。

    此致、
    Gokul

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    应用上述补丁后、获得了以下输出。 请帮助分析。

    [  203.051937] TX_COMPL: completed 1514 bytes, total_completed=3498479524, dql_avail=3028
    [  203.051946] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:4 pkt:1
    [  203.052050] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit skb_queue:4
    [  203.052058] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit tx psdata:0x332305c8
    [  203.052062] am65-cpsw-nuss c000000.ethernet: fragmented SKB
    [  203.052066] TX[4]: queued pkt_len=1514, total_queued=3498481038, dql_avail=1514
    [  203.052072] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit skb_queue:4
    [  203.052077] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit tx psdata:0x332305c8
    [  203.052081] am65-cpsw-nuss c000000.ethernet: fragmented SKB
    [  203.052084] TX[4]: queued pkt_len=1514, total_queued=3498482552, dql_avail=0
    [  203.052086] TX_COMPL: completed 1514 bytes, total_completed=3498481038, dql_avail=1514
    [  203.052090] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit skb_queue:4
    [  203.052094] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit tx psdata:0x332305c8
    [  203.052095] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:4 pkt:1
    [  203.052098] am65-cpsw-nuss c000000.ethernet: fragmented SKB
    [  203.052101] TX[4]: queued pkt_len=1514, total_queued=3498484066, dql_avail=0
    [  203.052107] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit skb_queue:4
    [  203.052106] TX_COMPL: completed 1514 bytes, total_completed=3498482552, dql_avail=1514
    [  203.052112] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit tx psdata:0x332305c8
    [  203.052113] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:4 pkt:1
    [  203.052117] am65-cpsw-nuss c000000.ethernet: fragmented SKB
    [  203.052120] TX[4]: queued pkt_len=1514, total_queued=3498485580, dql_avail=0
    [  203.052121] TX_COMPL: completed 1514 bytes, total_completed=3498484066, dql_avail=1514
    [  203.052126] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit skb_queue:4
    [  203.052128] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:4 pkt:1
    [  203.052130] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit tx psdata:0x332305c8
    [  203.052134] am65-cpsw-nuss c000000.ethernet: fragmented SKB
    [  203.052137] TX[4]: queued pkt_len=1514, total_queued=3498487094, dql_avail=0
    [  203.052139] TX_COMPL: completed 1514 bytes, total_completed=3498485580, dql_avail=1514
    [  203.052138] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_packets flow_idx: 0 desc 0x0000000940224d80
    [  203.052146] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_packets rx port_id:6
    [  203.052146] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:4 pkt:1
    [  203.052147] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit skb_queue:4
    [  203.052153] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit tx psdata:0x332305c8
    [  203.052154] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_packets rx csum_info:0x14ffff
    [  203.052159] TX_COMPL: completed 1514 bytes, total_completed=3498487094, dql_avail=3028
    [  203.052161] am65-cpsw-nuss c000000.ethernet: fragmented SKB
    [  203.052164] TX[4]: queued pkt_len=1514, total_queued=3498488608, dql_avail=1514
    [  203.052166] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:4 pkt:1
    [  203.052166] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_poll num_rx:1 64
    [  203.052170] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit skb_queue:4
    [  203.052175] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit tx psdata:0x332305c8
    [  203.052179] am65-cpsw-nuss c000000.ethernet: fragmented SKB
    [  203.052181] TX_COMPL: completed 1514 bytes, total_completed=3498488608, dql_avail=3028
    [  203.052182] TX[4]: queued pkt_len=1514, total_queued=3498490122, dql_avail=1514
    [  203.052187] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit skb_queue:4
    [  203.052189] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:4 pkt:1
    [  203.052192] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit tx psdata:0x332305c8
    [  203.052196] am65-cpsw-nuss c000000.ethernet: fragmented SKB
    [  203.052198] TX_COMPL: completed 1514 bytes, total_completed=3498490122, dql_avail=3028
    [  203.052199] TX[4]: queued pkt_len=1514, total_queued=3498491636, dql_avail=1514
    [  203.052204] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit skb_queue:4
    [  203.052205] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:4 pkt:1
    [  203.052208] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit tx psdata:0x332305c8
    [  203.052212] am65-cpsw-nuss c000000.ethernet: fragmented SKB
    [  203.052215] TX_COMPL: completed 1514 bytes, total_completed=3498491636, dql_avail=3028
    [  203.052215] TX[4]: queued pkt_len=1514, total_queued=3498493150, dql_avail=1514
    [  203.052220] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit skb_queue:4
    [  203.052222] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:4 pkt:1
    [  203.052224] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit tx psdata:0x332304b0
    [  203.052228] am65-cpsw-nuss c000000.ethernet: fragmented SKB
    [  203.052231] TX[4]: queued pkt_len=1234, total_queued=3498494384, dql_avail=280
    [  203.052231] TX_COMPL: completed 1514 bytes, total_completed=3498493150, dql_avail=1794
    [  203.052238] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:4 pkt:1
    [  203.052248] TX_COMPL: completed 1234 bytes, total_completed=3498494384, dql_avail=3028
    [  203.052255] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:4 pkt:1
    [  203.052410] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_packets flow_idx: 0 desc 0x0000000940224e00
    [  203.052419] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_packets rx port_id:6
    [  203.052424] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_packets rx csum_info:0x14ffff
    [  203.052433] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_poll num_rx:1 64
    [  203.056368] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_packets flow_idx: 0 desc 0x0000000940224e80
    [  203.056386] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_packets rx port_id:6
    [  203.056392] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_packets rx csum_info:0x14ffff
    [  203.056410] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_rx_poll num_rx:1 64
    [  203.056732] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit skb_queue:7
    [  203.056747] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_ndo_slave_xmit tx psdata:0x33230054
    [  203.056753] am65-cpsw-nuss c000000.ethernet: fragmented SKB
    [  203.056757] TX[7]: queued pkt_len=118, total_queued=10047972, dql_avail=2910
    [  203.056796] TX_COMPL: completed 118 bytes, total_completed=10047972, dql_avail=3028
    [  203.056810] am65-cpsw-nuss c000000.ethernet: am65_cpsw_nuss_tx_compl_packets:7 pkt:1

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好:Tanmay、Gokul、

    请帮助分析基于您提供的补丁程序的日志、谢谢! 客户解决这个问题比较紧急。

    Kevin

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jiance:

    当您使用打印机运行时、似乎没有重现该错误。

    我想看看当首次看到 isue 时 dql 处于什么状态、以及我们是否有时比这更早看到任何不匹配。 您共享的日志中没有“不匹配“的打印内容。 在工作阶段不会有明显的事情。

    但可能有太多的打印件、这可能会导致延迟处理并导致问题不出现。 为此,您可以:

    1. 从 cpsw 驱动程序中禁用除我补丁中存在的日志之外的所有其他日志(例如上面从 am65_cpsw_nuss_tx_compl_packets、am65_cpsw_nuss_rx_packets 等中看到的日志)
    2. 将 kernel.printk sysctl 更改为在控制台上显示错误但不显示调试消息。
    3. 出现问题时、请保存 dmesg、以便您还有所有调试消息。

    这将帮助我们更好地了解系统中正在发生的情况。

    由于我无法在我的设置中重新创建该文件、因此我没有太多的能力对此进行实验并查看正在进行的操作。

    此致、
    Tanmay  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    当崩溃发生时,内核在崩溃前未能打印出“不匹配“。

    [   10.887197] am65-cpsw-nuss c000000.ethernet eth3: Link is Up - 1Gbps/Full - flow control off
    [   10.889120] ft_memdev_open! num:0 
    [   10.893699] br0: port 4(eth3) entered blocking state
    [   10.893720] br0: port 4(eth3) entered forwarding state
    [   10.916284] ft_memdev_open! num:0 
    [   12.912600] configfs-gadget.g_multi gadget.0: HOST MAC 1c:ba:8c:a2:ed:6a
    [   12.919441] configfs-gadget.g_multi gadget.0: MAC 1c:ba:8c:a2:ed:6b
    
     _____                    _____           _         _   
    |  _  |___ ___ ___ ___   |  _  |___ ___  |_|___ ___| |_ 
    |     |  _| .'| . | . |  |   __|  _| . | | | -_|  _|  _|
    |__|__|_| |__,|_  |___|  |__|  |_| |___|_| |___|___|_|  
                  |___|                    |___|            
    
    Arago Project j784s4-evm ttyS2
    
    Arago 2025.01 j784s4-evm ttyS2
    
    j784s4-evm login: [   17.838238] ------------[ cut here ]------------
    [   17.842872] kernel BUG at lib/genalloc.c:508!
    [   17.847224] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
    [   17.853999] Modules linked in: 8021q garp mrp debug(O) ft_net_tc8(O) cryptodev(O) ft_spinlock(O) ft_memdev(O) bridge stp llc usb_f_acm u_serial usb_f_ncm u_ether libcomposite rpmsg_ctrl rpmsg_char cdns3 spidev cdns_usb_common wave5 videobuf2_dma_contig crct10dif_ce v4l2_mem2mem videobuf2_v4l2 videobuf2_memops videobuf2_common omap_hwspinlock pvrsrvkm(O) videodev omap_mailbox mc sa2ul ti_k3_r5_remoteproc ti_k3_dsp_remoteproc cdns3_ti ti_k3_common spi_omap2_mcspi rti_wdt drm drm_panel_orientation_quirks
    [   17.898412] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G           O       6.12.17-ti #1
    [   17.906760] Tainted: [O]=OOT_MODULE
    [   17.910241] Hardware name: Texas Instruments J784S4 EVM (DT)
    [   17.915894] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [   17.922849] pc : gen_pool_free_owner+0x104/0x110
    [   17.927475] lr : gen_pool_free_owner+0xa8/0x110
    [   17.932014] sp : ffff80008000bc90
    [   17.935328] x29: ffff80008000bc90 x28: 0000000000000000 x27: ffff80008000bd90
    [   17.942461] x26: ffff0008332ec080 x25: ffff0008332ec590 x24: 0000000000000007
    [   17.949593] x23: 0000000000000080 x22: 0000000000000000 x21: 0000000000000001
    [   17.956724] x20: ffff00083441b440 x19: ffff0008c0142480 x18: 0000000000000000
    [   17.963855] x17: ffff8008f62cc000 x16: ffff800080008000 x15: 0000ffff6572e6a0
    [   17.970988] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
    [   17.978118] x11: ffff8000813ed000 x10: ffff800080b84938 x9 : 0000007000000000
    [   17.985248] x8 : 0000000000000037 x7 : fffffffffffffe00 x6 : fffffffffffffdff
    [   17.992376] x5 : ffff800081175370 x4 : 000000003ffffcc0 x3 : ffff8000813ed040
    [   17.999514] x2 : ffffffffffffffff x1 : 0000000000000200 x0 : 0000000000000001
    [   18.006646] Call trace:
    [   18.009088]  gen_pool_free_owner+0x104/0x110
    [   18.013360]  k3_cppi_desc_pool_free+0x1c/0x28
    [   18.017716]  am65_cpsw_nuss_xmit_free+0xe0/0x128
    [   18.022336]  am65_cpsw_nuss_tx_compl_packet_skb+0x50/0xa0
    [   18.027741]  am65_cpsw_nuss_tx_poll+0x130/0x598
    [   18.032280]  __napi_poll+0x38/0x17c
    [   18.035775]  net_rx_action+0x15c/0x2b8
    [   18.039525]  handle_softirqs+0x104/0x248
    [   18.043449]  __do_softirq+0x14/0x20
    [   18.046934]  ____do_softirq+0x10/0x1c
    [   18.050595]  call_on_irq_stack+0x24/0x4c
    [   18.054517]  do_softirq_own_stack+0x1c/0x28
    [   18.058701]  irq_exit_rcu+0x8c/0xc4
    [   18.062190]  el1_interrupt+0x38/0x68
    [   18.065772]  el1h_64_irq_handler+0x18/0x24
    [   18.069869]  el1h_64_irq+0x64/0x68
    [   18.073270]  default_idle_call+0x28/0x3c
    [   18.077192]  do_idle+0x200/0x258
    [   18.080426]  cpu_startup_entry+0x38/0x3c
    [   18.084349]  secondary_start_kernel+0x124/0x144
    [   18.088878]  __secondary_switched+0xb8/0xbc
    [   18.093064] Code: c8017c40 35ffffa1 17fffff0 d4210000 (d4210000) 
    [   18.099153] ---[ end trace 0000000000000000 ]---
    [   18.103767] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt
    [   18.111150] SMP: stopping secondary CPUs
    [   18.115075] Kernel Offset: 0x80000 from 0xffff800080000000
    [   18.120546] PHYS_OFFSET: 0xfff1000080000000
    [   18.124716] CPU features: 0x08,00002002,80200000,4200420b
    [   18.130102] Memory Limit: none
    [   18.133147] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Tanmay、

    您还需要客户提供任何其他信息来分析问题? 客户提供的上述信息是否足够?

    谢谢、

    Kevin

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Kevin、Jiance:

    发生崩溃时、内核在崩溃前似乎无法输出“不匹配“。

    这是意料之外的。 所有提示都指向正在发生的 dql 不匹配。 似乎发生的情况是,我们正在发送数据包的地方,但没有要求完成。 在这种情况下、dql 将变为负数、用于队列 5。 我们可以在日志中看到队列 2 发生了正确的情况。

    根据您的日志、您的 TX 和 tx_compl 日志的时间戳与发生崩溃时不同。 崩溃发生得早得多。 您是否有关于崩溃时间的日志?

    由于串行端口非常慢、我将打印重定向到文件。

    我同意这一点。 这是必须做到的。

    摄像头应用是我能够在 EVM 上运行的。 最好能以某种方式在设置中重新创建它。

    您的 DMA 通道分配是什么样子的? 它与默认的视觉应用相同吗? 还是改变了?

    您可以尝试在 EVM 上重新创建。

    谢谢。此致、
    Tanmay

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    从您的日志中、您的 tx 和 tx_compl 日志的时间戳与发生崩溃时不同。 崩溃发生得早得多。 您是否有关于崩溃时间的日志?

    抱歉、可能存在一些误解。 内核崩溃和超时是与以太网问题相关的两种不同现象。 因此,我提供的日志代表了两个不同的开机循环的复制场景。 对于崩溃情况、由于不匹配的打印输出为 pr_error、因此它应该在崩溃堆栈跟踪之前显示。 然而,在现实中,它没有被显示。 因此、前一个答复的日志是崩溃期间的所有日志。

    [报价 userid=“498482" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1580429/tda4vh-q1-cpsw9g-native-drive-encounters-the-netdev-watchdog-issue/6127909

    摄像头应用是我能够在 EVM 上运行的。 最好能以某种方式在设置中重新创建它。

    您的 DMA 通道分配是什么样子的? 它与默认的视觉应用相同吗? 还是改变了?

    您可以尝试在 EVM 上重新创建

    [/报价]

    关于此主题、我将与摄像头应用团队确认、并评估我们是否可以在 EVM 上运行摄像头演示。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、

    如果超时、我们是否会看到任何不匹配的打印件。 我认为两者的根本原因可能是相同的。 崩溃最可能是由于描述符位图中发生了双重释放。  如果内核未崩溃、这也可能导致 dql 中出现问题并触发看门狗复位。 请注意、不匹配可能发生在看门狗超时开始之前。

    您能尝试将单个队列用于 CPSW 吗? 这是为了我们没有并发性。 您是否为某件事使用了多个队列、或者这对您来说合适?

    您可以使用以下补丁程序更改为单个默认队列:

    diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
    index 84cd71477b04..ac9d0d29d2ad 100644
    --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
    +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
    @@ -3983,7 +3983,8 @@ static int am65_cpsw_nuss_probe(struct platform_device *pdev)
     
     	common->rx_flow_id_base = -1;
     	init_completion(&common->tdown_complete);
    -	common->tx_ch_num = AM65_CPSW_DEFAULT_TX_CHNS;
    +	// common->tx_ch_num = AM65_CPSW_DEFAULT_TX_CHNS;
    +	common->tx_ch_num = 1;
     	common->rx_ch_num_flows = AM65_CPSW_DEFAULT_RX_CHN_FLOWS;
     	common->pf_p0_rx_ptype_rrobin = true;
     	common->default_vlan = 1;
    

    此致、
    Tanmay

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    好的、我来试一下、然后提供反馈。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    好消息! 更改为单通道配置后、我进行了统一测试。
    测试方法如下:

    打开并执行 TCP 客户端发送测试。 分别运行已修补和未修补的内核以进行 10 次测试。

    测试结果如下:Ω

    无 补丁: net timeout:4, kernel crash:6,  normal:0
    已修补:  网络 超时:0、 内核 崩溃:0、 正常:10

     

    单通道 PTCHED iperf3 测试:

    Accepted connection from 192.168.0.97, port 58397
    [  5] local 192.168.0.2 port 5201 connected to 192.168.0.97 port 58398
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-1.00   sec   112 MBytes   940 Mbits/sec                  
    [  5]   1.00-2.00   sec   113 MBytes   945 Mbits/sec                  
    [  5]   2.00-3.00   sec   112 MBytes   943 Mbits/sec                  
    [  5]   3.00-4.00   sec   113 MBytes   944 Mbits/sec                  
    [  5]   4.00-5.00   sec   113 MBytes   945 Mbits/sec                  
    [  5]   5.00-6.00   sec   113 MBytes   947 Mbits/sec                  
    [  5]   6.00-7.00   sec   113 MBytes   946 Mbits/sec                  
    [  5]   7.00-8.00   sec   113 MBytes   947 Mbits/sec                  
    [  5]   8.00-9.00   sec   112 MBytes   944 Mbits/sec                  
    [  5]   9.00-10.00  sec   112 MBytes   943 Mbits/sec                  
    [  5]  10.00-10.01  sec   640 KBytes   931 Mbits/sec                  
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-10.01  sec  1.10 GBytes   945 Mbits/sec                  receiver

    您能否为 CPSW 使用单个队列。 这是为了我们没有并发性。 您是否为某件事使用了多个队列?

    根据测试结果、很明显存在并发问题。 这表明当前驱动程序及其并发方案在某些情况下确实存在错误。

    基于这一结果、我想知道如果将该贴片用作预防措施并应用于大规模生产的产品、会产生什么影响。 是否会出现任何性能瓶颈? 毕竟、我们使用 CPSW9G 的 6 个端口。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jiance:

    队列是每个端口的。 因此、如果您使用 6 个 CPSW 端口、将会有 6 个队列、但网络路由器中的队列不同。 因此它不会提高每个端口的性能。

    但是、如果您有任何从 Linux (tcprio 或 mqprio qdisc) 输出的 QoS 流量、或者如果您希望降低 CPU 利用率、则需要使用它。 您可以将不同的队列绑定到不同的内核上、这有助于 Tx 处理一点点。 除此之外、拥有单个队列没有显著影响。

    如果您看到的 CPU 利用率在正常情况下低于限制、并且您没有使用上述 qdisc、那么使用单个队列不会产生太大影响。

    此致、
    Tanmay

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您的 DMA 信道分配是怎样的? 它与默认的视觉应用相同吗? 还是更改了?

    我们已经对 RTOS-SDK 中 CSI 的 DMA 进行了一些修改。

    diff --git a/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drv.c b/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drv.c
    index bdca27f0..c9a097b7 100755
    --- a/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drv.c
    +++ b/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drv.c
    @@ -1094,7 +1094,8 @@ static int32_t CsitxDrv_createChQueues(CsitxDrv_ChObj *chObj)
                 qObj->chObj = chObj;
                 qObj->frm   = NULL;
                 qObj->trpd =
    -                    (CSL_UdmapCppi5TRPD *)CsitxDrv_getTrpdMemAddr(instObj->drvInstId,chIdx,qCnt);
    +                    (CSL_UdmapCppi5TRPD *)CsitxDrv_getTrpdMemAddr(chIdx,
    +                                                                  qCnt);
                 tempRetVal = CsitxDrv_udmaTxTrpdInit(
                                     &chObj->txChObj,
                                     (uint8_t *)qObj->trpd,
    diff --git a/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drvUdma.c b/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drvUdma.c
    index 5d396055..d1e0c1e8 100755
    --- a/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drvUdma.c
    +++ b/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drvUdma.c
    @@ -67,7 +67,7 @@
     /*
      * UDMA Memories
      */
    -static uint8_t gCsitxRingMem[CSITX_INSTANCE_ID_MAX][CSITX_NUM_CH][CSITX_DRV_RING_MEM_SIZE_ALIGN]
    +static uint8_t gCsitxRingMem[CSITX_NUM_CH][CSITX_DRV_RING_MEM_SIZE_ALIGN]
                                 __attribute__((aligned(UDMA_CACHELINE_ALIGNMENT)));
     #if defined (SOC_J721E)
     static uint8_t gCsitxCompRingMem[CSITX_NUM_CH][CSITX_DRV_RING_MEM_SIZE_ALIGN]
    @@ -76,7 +76,7 @@ static uint8_t gCsitxTdCompRingMem[CSITX_NUM_CH][CSITX_DRV_RING_MEM_SIZE_ALIGN]
                                 __attribute__((aligned(UDMA_CACHELINE_ALIGNMENT)));
     #endif
     static uint8_t gCsitxUdmaTprdMem
    -        [CSITX_INSTANCE_ID_MAX][CSITX_NUM_CH][CSITX_TX_QUEUE_DEPTH_PER_CH][CSITX_DRV_TRPD_SIZE_ALIGN]
    +        [CSITX_NUM_CH][CSITX_TX_QUEUE_DEPTH_PER_CH][CSITX_DRV_TRPD_SIZE_ALIGN]
                                 __attribute__((aligned(UDMA_CACHELINE_ALIGNMENT)));
     extern CsitxDrv_CommonObj gCsitxCommonObj;
     #if (CSITX_DRV_ENABLE_DEBUG == 1U)
    @@ -103,8 +103,8 @@ int32_t CsitxDrv_setDMACfgParams(CsitxDrv_ChObj *chObj)
         /* Init UDMA channel parameters */
         chType = UDMA_CH_TYPE_TX;
         UdmaChPrms_init(&chObj->chParams, chType);
    -    chObj->trpdMem = &gCsitxUdmaTprdMem[chObj->instObj->drvInstId][chObj->psilThreadId][0U][0U];
    -    chObj->txFqRingMem = &gCsitxRingMem[chObj->instObj->drvInstId][chObj->psilThreadId][0U];
    +    chObj->trpdMem = &gCsitxUdmaTprdMem[chObj->psilThreadId][0U][0U];
    +    chObj->txFqRingMem = &gCsitxRingMem[chObj->psilThreadId][0U];
     #if defined (SOC_J721E)
         chObj->txCqRingMem = &gCsitxCompRingMem[chObj->psilThreadId][0U];
         chObj->txTdCqRingMem = &gCsitxTdCompRingMem[chObj->psilThreadId][0U];
    @@ -858,9 +858,9 @@ void CsitxDrv_cacheInv(const void * addr, uint32_t size)
         return;
     }
     
    -uint8_t* CsitxDrv_getTrpdMemAddr(uint32_t instid, uint32_t chIdx, uint32_t qCnt)
    +uint8_t* CsitxDrv_getTrpdMemAddr(uint32_t chIdx, uint32_t qCnt)
     {
    -    return (&gCsitxUdmaTprdMem[instid][chIdx][qCnt][0U]);
    +    return (&gCsitxUdmaTprdMem[chIdx][qCnt][0U]);
     }
     /* ========================================================================== */
     /*                       Static Function Definitions                          */
    diff --git a/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drvUdma.h b/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drvUdma.h
    index f1bdfef7..a1221c3d 100755
    --- a/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drvUdma.h
    +++ b/pdk_j784s4_11_00_00_21/packages/ti/drv/csitx/src/csitx_drvUdma.h
    @@ -109,7 +109,7 @@ void CsitxDrv_cacheWb(const void *addr, uint32_t size);
     
     void CsitxDrv_cacheInv(const void * addr, uint32_t size);
     
    -uint8_t* CsitxDrv_getTrpdMemAddr(uint32_t instid, uint32_t chIdx, uint32_t qCnt);
    +uint8_t* CsitxDrv_getTrpdMemAddr(uint32_t chIdx, uint32_t qCnt);
     /* ========================================================================== */
     /*                       Static Function Definitions                          */
     /* ========================================================================== */
    

    TDA4VH 支持两个 CSITx 实例。 在本机 SDK 中、两个 csitx 共享相同的 umda 资源。 在该项目中、将同时使用两个 csitx、因此 umda 资源(包括 gCsitxRingMem 和 gCsitxUdmaTprdMem 资源)需要按实例 ID 进行区分

    其他与 DMA 相关的配置与 SDK 保持一致、且未经修改。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [报价 userid=“498482" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1580429/tda4vh-q1-cpsw9g-native-drive-encounters-the-netdev-watchdog-issue/6128298

    但是、如果您有任何从 Linux (tcprio 或 mqprio qdisc) 输出的 QoS 流量、或者如果您希望降低 CPU 利用率、则需要使用它。 您可以将不同的队列绑定到不同的内核上、这有助于 Tx 处理一点点。 除此之外、拥有单个队列没有显著影响。

    如果您看到的 CPU 利用率在正常情况下低于限制、并且您没有使用上述 qdisc、那么使用单个队列不会产生太大影响

    [/报价]

    好的、我将检查终端客户的要求、看看他们是否会使用您提到的功能。 但我认为我们仍应调查此问题的根本原因、以便我们可以在后续项目中继续使用 A 内核本机以太网驱动程序。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    当我们使用上述单通道补丁来测试以太网时、它当前工作正常。 但是、SPI 出现问题。 我们发现了这一点 贴片之后添加了另一个抗混叠滤波器 、SPI 将在开机后几分钟内正常工作、但一段时间后、 发送 DMA 会卡住 回滚补丁解决了问题并使 SPI 功能正常。

    这是我们的 SPI-DMA 器件树配置。

    &main_spi0 {
    	status="okay";
    	spi-slave;
    	pinctrl-names = "default";
    	pinctrl-0 = <&main_spi0_pins_default>;
    	ti,spi-num-cs = <1>;
    	dmas = <&main_udmap 0xc600>, <&main_udmap 0x4600>; /* drivers/dma/ti/k3-psil-j784s4.c */
    	dma-names = "tx0", "rx0";
    	slave@0 {
    		spi-max-frequency = <10000000>;
    		reg = <0>;
    		compatible = "linux,spidev";
    		spidev_gpio_rdy{
    			spi-rdy-gpios = <&main_gpio0 16 GPIO_ACTIVE_HIGH>;
    		};
    	};
    };

    我们添加了一个 GPIO(通用输入/输出)来启动发送到 SPI 主器件的通信请求。

    diff --git a/board-support/ti-linux-kernel-6.12.17+git-ti/drivers/spi/spi-omap2-mcspi.c b/board-support/ti-linux-kernel-6.12.17+git-ti/drivers/spi/spi-omap2-mcspi.c
    index 532b2e9c3..db3458cd0 100644
    --- a/board-support/ti-linux-kernel-6.12.17+git-ti/drivers/spi/spi-omap2-mcspi.c
    +++ b/board-support/ti-linux-kernel-6.12.17+git-ti/drivers/spi/spi-omap2-mcspi.c
    @@ -30,11 +30,14 @@
     #include "internals.h"
     
     #include <linux/platform_data/spi-omap2-mcspi.h>
    +#include <dt-bindings/gpio/gpio.h>
    +#include <linux/of_gpio.h>
     
     #define OMAP2_MCSPI_MAX_FREQ		48000000
     #define OMAP2_MCSPI_MAX_DIVIDER		4096
     #define OMAP2_MCSPI_MAX_FIFODEPTH	64
     #define OMAP2_MCSPI_MAX_FIFOWCNT	0xFFFF
    +#define OMAP2_MCSPI_MAX_TRXSIZE		10240
     #define SPI_AUTOSUSPEND_TIMEOUT		2000
     
     #define OMAP2_MCSPI_REVISION		0x00
    @@ -528,6 +531,11 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct spi_transfer *xfer,
     	dma_async_issue_pending(mcspi_dma->dma_rx);
     	omap2_mcspi_set_dma_req(spi, 1, 1);
     
    +	if (spi_controller_is_target(spi->controller)) {
    +		gpio_set_value(spi->controller->request_gpio, 1);
    +		dev_dbg(&spi->dev,"spi gpio reqest 1\n");
    +	}
    +
     	ret = mcspi_wait_for_completion(mcspi, &mcspi_dma->dma_rx_completion);
     	if (ret || mcspi->target_aborted) {
     		dmaengine_terminate_sync(mcspi_dma->dma_rx);
    @@ -535,6 +543,7 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct spi_transfer *xfer,
     		return 0;
     	}
     
    +	dev_dbg(&spi->dev,"spi rx completed\n");
     	for (x = 0; x < nb_sizes; x++)
     		kfree(sg_out[x]);
     
    @@ -652,6 +661,13 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
     		int ret;
     
     		ret = mcspi_wait_for_completion(mcspi, &mcspi_dma->dma_tx_completion);
    +
    +		dev_dbg(&spi->dev,"spi tx completed\n");
    +		if (spi_controller_is_target(spi->controller)) {
    +			gpio_set_value(spi->controller->request_gpio, 0);
    +			dev_dbg(&spi->dev,"spi gpio reqest 0\n");
    +		}
    +
     		if (ret || mcspi->target_aborted) {
     			dmaengine_terminate_sync(mcspi_dma->dma_tx);
     			omap2_mcspi_set_dma_req(spi, 0, 0);
    @@ -1364,6 +1380,9 @@ static int omap2_mcspi_controller_setup(struct omap2_mcspi *mcspi)
     	struct omap2_mcspi_regs	*ctx = &mcspi->ctx;
     	int			ret = 0;
     
    +	struct device_node *request_node = NULL;
    +	struct device_node *child = NULL;
    +
     	ret = pm_runtime_resume_and_get(mcspi->dev);
     	if (ret < 0)
     		return ret;
    @@ -1372,6 +1391,24 @@ static int omap2_mcspi_controller_setup(struct omap2_mcspi *mcspi)
     			OMAP2_MCSPI_WAKEUPENABLE_WKEN);
     	ctx->wakeupenable = OMAP2_MCSPI_WAKEUPENABLE_WKEN;
     
    +	if (spi_controller_is_target(ctlr)) {
    +		if(ctlr->dev.of_node) {
    +			for_each_child_of_node(ctlr->dev.of_node, child) {
    +				if(spi_controller_is_target(ctlr)) {
    +					request_node = of_find_node_by_name(child, "spidev_gpio_rdy");
    +					if (NULL == request_node) {
    +						printk(KERN_ERR "request failed %d\n", ret);
    +					} else {
    +						ctlr->request_gpio = of_get_named_gpio(request_node, "spi-rdy-gpios", 0);
    +						printk(KERN_ERR "request gpio %d\n", ctlr->request_gpio);
    +						gpio_direction_output(ctlr->request_gpio, 0);
    +					}
    +				}
    +			}
    +			of_node_put(ctlr->dev.of_node);
    +		}
    +	}
    +
     	omap2_mcspi_set_mode(ctlr);
     	pm_runtime_mark_last_busy(mcspi->dev);
     	pm_runtime_put_autosuspend(mcspi->dev);
    @@ -1433,15 +1470,17 @@ static int omap_mcspi_runtime_resume(struct device *dev)
     
     static struct omap2_mcspi_platform_config omap2_pdata = {
     	.regs_offset = 0,
    +	.max_xfer_len = OMAP2_MCSPI_MAX_TRXSIZE - 1,
     };
     
     static struct omap2_mcspi_platform_config omap4_pdata = {
     	.regs_offset = OMAP4_MCSPI_REG_OFFSET,
    +	.max_xfer_len = OMAP2_MCSPI_MAX_TRXSIZE - 1,
     };
     
     static struct omap2_mcspi_platform_config am654_pdata = {
     	.regs_offset = OMAP4_MCSPI_REG_OFFSET,
    -	.max_xfer_len = SZ_4K - 1,
    +	.max_xfer_len = OMAP2_MCSPI_MAX_TRXSIZE - 1,
     };
     
     static const struct of_device_id omap_mcspi_of_match[] = {
    

    因此、很奇怪、当以太网更改为单通道配置时、会影响 SPI 的正常运行。

    请提供与 DMA 相关的寄存器列表、以便我们可以检查 DMA 的状态是否异常。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    SPI 的工作流程如下:
    1.VH 充当从器件、并升高 GPIO。
    2. RH850 充当主设备、在检测到 GPIO 时启动通信。
    3、通信完成后、VH 降低 GPIO。

    使用单通道补丁后、在 TX DMA 运行期间会阻止 SPI。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您的 DMA 信道分配是怎样的? 它与默认的视觉应用相同吗? 还是更改了?

    在就 UDMA 相关问题在 MSC 和 LDC 的调试过程中、在内部咨询 DSP 团队之后、我们采用了 TI 提供的修改建议:

    TDA4VH-Q1:SDK11.0 MSC “ch0 的 UDMA 输出环出队失败!!“ -处理器论坛 — 处理器- TI E2E 支持论坛

    请进行内部全面检查、以确定上述修改是否会影响以太网的 DMA。

    此外、我注意到在另一篇文章中、其他用户还报告说、在使用 VPAC 期间、还存在以太网超时问题。 但是、在这篇文章中、TI 未就 VPAC 如何影响以太网的 DMA 提供任何说明。

    TDA4VH-Q1:netdev 看门狗:CPU:4:传输队列 2 超时 508184ms — 处理器论坛-处理器 — TI E2E 支持论坛

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    崩溃最可能是由于描述符位图中发生了双重释放。

    关于“双重释放“问题、我们进行了一些调查、确实发现了 DMA 组件中的硬件错误。

    e2e.ti.com/.../UDMA_5F00_Problem_5F00_Troubleshooting_5F00_Record.pdf

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jiance:

    我们的专家内部有一个关于这个超时问题的建议、 只需增加硬件中 LDC 和 MSC 的超时即可。 在负载过重的系统中、出队可能需要更多时间、因此建议增加超时。 可以尝试一下吗? 谢谢。

    Kevin