[参考译文] PROCESSOR-SDK-AM64X：HSR PRU 固件不会删除重复数据包

您好、天一：  

感谢您分享这些有关您在 SDK 11.0 上看到的行为的详细信息。  

我发现 HSR 数据包的 eth1 和 eth2 队列中有两个 IRQ。 但是、PRU 固件应删除重复的数据包、我期望只有一个 IRQ。  [/报价]

为了仔细检查、在之前的 SDK 9.2 版本上、使用相同的步骤、您还看到 eth1 和 eth2 都显示了 IRQ 计数？ 接收到的每个数据包的第一个副本是否可能更改/替换帧到达的端口？ 或者、您是否希望每个数据包的第一个副本始终到达一个特定端口？

-对于 HSR 脚本、您能否确认我们需要先启动 icssg (up eth1 和 eth2)、然后再启动 hsr0 接口？ （我会说是，因为在这种情况下 HSR 卸载工作正常）

当您在上 hsr0 接口之前没有先上 eth1 和 eth2 时、您是否在默认的 1Gbps 链路速度下看到 eth1 和 eth2 IRQ 行为的问题？

您是否还可以尝试使用以下脚本在 SDK 11.0 上运行 HSR？ 下面的 HSR 脚本主要用于在 SDK 10.1 上进行测试、与用于 SDK 9.2 的版本略有不同

x=1
if=$1
ifa=eth1
ifb=eth2
ip=$4
forwarding=$5
cutthruq=$6
mac=`ifconfig $ifa | grep ether | cut -d " " -f 10`
device="platform/icssg1-eth"

# Helper API
err_on_cmd() {                 
        if [ $? != 0 ]; then   
                echo "FAILED: $1"
                echo "HSR OFFload failed in $x 'th try"
                echo "Going Back to dual EMAC mode"
                icssg_disable_hsr_offload
                exit 1;
        fi                     
} 

# Enable HSR Offload mode.

usage() {
        echo "USAGE: $0 <hsr_iface> <on/off> <enable/disable> <ip> <forwarding_method> <cut-thru-que"
        echo ""
        echo "  hsr_iface implies name of the hsr interface to be created i.e. hsr0."
        echo "  On implies hsr offloading is done in hardware, off implies same is done in sw."
        echo "  enables / disables the hsr offload mechanism, this willd delete the hsr iface."
        echo "  ip to be assigned to hsr_iface"
        echo "  forwarding_method implies cut-thru is enabled or store and forward"
        echo "  cut-thru-queue implies the queues on which cut-thru is enabled"
        echo "  Sample cmd - $0 hsr0 on enable 192.168.10.10 cutthru 257"
        echo "  Sample cmd - $0 hsr0 on enable 192.168.10.10"
        echo ""
        exit   
}

icssg_enable_hsr_offload () {

        if [ "$#" != "1" ]
        then
              usage  
        fi

        if [ "$1" != "on" ] && [ "$1" != "off" ]
        then
                usage
        fi

        # Enable all offloads.
        ethtool -K $ifa hsr-fwd-offload $1
        ethtool -K $ifa hsr-dup-offload $1
        ethtool -K $ifa hsr-tag-ins-offload $1
        ethtool -K $ifa hsr-tag-rm-offload $1
        ethtool -K $ifb hsr-fwd-offload $1
        ethtool -K $ifb hsr-dup-offload $1
        ethtool -K $ifb hsr-tag-ins-offload $1
        ethtool -K $ifb hsr-tag-rm-offload $1
        ethtool -k $ifa | grep hsr
        ethtool -k $ifb | grep hsr

        sleep 2

        ip link set dev $ifa address $mac
        ip link set dev $ifb address $mac

        if [[ "$forwarding" == "cutthru" ]]; then
                # Enable cut-thru
                echo "Enabling cutthru $cutthruq"
                devlink dev param set platform/icssg1-eth name cut_thru value $cutthruq cmode runtime
        else 
                echo "not enabling cutthru"
        fi

        ip link add name $if type hsr slave1 $ifa slave2 $ifb supervision 45 version 1

        sleep 3

        ip addr add $ip/24 dev $if
        ip link set $if up

        #show cut-through properties                                                                
        devlink dev param show

}

icssg_disable_hsr_offload () {
        ip link set $if down
        sleep 1
        ip link delete $if  2> /dev/null
        sleep 1
}

if [[ "$2" != "on" ]] && [[ "$2" != "off" ]]; then
        echo "second if"
        usage
fi

if [[ "$3" != "enable" ]] && [[ "$3" != "disable" ]]; then
        echo "third if"
        usage
fi

# Test starts
echo "ip=$ip"
echo "if=$if"
echo "mac=$mac"
echo "slave-a=$ifa"
echo "slave-b=$ifb"
echo "device=$device"
echo "hw_offload=$2"
echo "forwarding_method=$forwarding"

if [[ "$3" == "enable" ]]; then
        icssg_enable_hsr_offload $2
else
        icssg_disable_hsr_offload
fi

-这样做时、如果我们要首先设置 ethtool 100 Mbps 链路速度 eth1 和 eth2、则“测试设备“无法接收任何数据包、这是正常的吗？ 也许你能尝试在你这边重现这个吗?  [/报价]

我需要尝试测试一下、看看是否可以重现问题。 根据我的理解、我们针对 HSR 的内部测试侧重于 1Gbps、因此 100Mbps 可能存在一些问题。 不幸的是、我本周不在办公室、但应该回到办公室、以便能够在下周进行测试。

-道林

[/quote]

尊敬的 Daolin：  

感谢您的快速响应。

为了仔细检查、在之前的 SDK 9.2 版本上、使用相同的步骤、您还看到 eth1 和 eth2 都显示了 IRQ 计数？ 接收到的每个数据包的第一个副本是否可能更改/替换帧到达的端口？ 或者、您是否希望每个数据包的第一个副本始终到达一个特定端口？

是、在之前的 SDK 9.X 上 而当第一 hsr0 然后 eth1 和 eth2 ,我确实发现了类似的问题。 我想我们需要 先向上计数 eth1 和 eth2、然后向上计数 hsr0 。 （如 SDK 9.X 中所述）。 当我在 SDK 上进行相同的测试、但首先是 eth1 和 eth2、然后是 hsr0 时、我只找到一个 IRQ、这意味着数据包已通过 PRU 固件删除。 我期望 SDK 11.X 具有相同的结果

当您在上 hsr0 接口之前没有先上 eth1 和 eth2 时、您是否在默认的 1Gbps 链路速度下看到 eth1 和 eth2 IRQ 行为的问题？

在这里、我们的目标是 100Mbps 链路速度、我可以快速进行尝试。  

ip link set dev "$ifa" address "$mac"
ip link set dev "$ifb" address "$mac"

ip link add name $if type hsr slave1 "$ifa" slave2 "$ifb" supervision 45 version 1

sleep 3

ip addr add "$ip"/24 dev $if
ip link set $if up

ip link set $ifa up                            
sleep 1                                       
                                            
ip link set $ifb up                                                                   
sleep 1

我会再次检查以确定。  

根据 SDK TI 文档、我在这里可能有几个问题：  

- 9.X： https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_02_01_10/exports/docs/linux/Kernel_Drivers highlight=hsr%20 卸载 Foundational_Components /内核/Network/HSR_Offload.html

- 11.X : https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/11_00_09_04/exports/docs/linux/Foundational_Components /内核/ Kernel_Drivers 网络/HSR_Offload.html

该脚本对如何启用 HSR 减轻 PRU 负载进行了一些更改。 特别是关于在 SDK 9.X 上打开 hsr0 之前打开 eth1 和 eth2。  在 SDK 11.X 上、我们启动了 hsr0。 你知道是否有任何原因吗?  

我尝试总结所有从以前的消息观察结果基于 SDK 11.X 上的测试,在 100 Mbps 的链路速度:  

-如果打开 hsr0、则 eth1 和 eth2、HSR 接口会接收 HSR 数据包、但不会根据 IRQ 删除重复的数据包。 ==> ko（这里我假设我们需要先启动 eth1 和 eth2（启动 icssg 固件）,然后启动 hsr0 如 SDK 9.X 中突出显示,在 11.X 中未突出显示,是否可以在您这边重现此?)

-如果打开 eth1 和 eth2 然后打开 hsr0 （如建议的 SDK 9.X ）, HSR 接口会接收数据包,并 根据 IRQ 删除 HSR 重复数据包。 =>确定

-如果我们为 eth1 和 eth2 设置 ethtool 100Mbps 链路速度+ 将 eth1 和 eth2 调到 hsr0 （如建议的 SDK 9.X ）, HSR 接口会接收数据包,并 根据 IRQ 删除 HSR 重复数据包。 ==> Ko（对我来说，使用 ethtool 设置接口链路速度时不应发生这种情况，您是否可以重现此情况？）

-如果打开 eth1 和 eth2、然后打开 hsr0 （如 SDK 9.X）、然后关闭+打开 eth1 和 eth2、 则不会根据 IRQ 删除 HSR 重复的数据包。  => Ko（对我来说，在重新启动 PRU_ICSSG 固件时不应该发生这种情况，是否可以在您这边重现此情况？）

-天一  

您好、天一：  

是以前的 SDK 9.X 而当第一 hsr0 然后 eth1 和 eth2 ,我确实发现了类似的问题。 我想我们需要 先向上计数 eth1 和 eth2、然后向上计数 hsr0 。 （如 SDK 9.X 中所述）。 当我在 SDK 上进行相同的测试、但首先是 eth1 和 eth2、然后是 hsr0 时、我只找到一个 IRQ、这意味着数据包已通过 PRU 固件删除。 我期望 SDK 11.X

我在设置 HSR 接口之前在内部检查了 eth1 和 eth2 是否保持不变、这是正确的、因为脚本应确保在 HSR 设置之前保持 eth1 和 eth2。 下面是我在上一次回复中分享的脚本的稍微更新版本。 在该脚本中、应确保在运行脚本之前保持 eth1 和 eth2。 请注意、由于我目前不在办公室、我尚未能够测试此修改后的脚本。  

x=1
if=$1
ifa=eth1
ifb=eth2
ip=$4
forwarding=$5
cutthruq=$6
mac=`ifconfig $ifa | grep ether | cut -d " " -f 10`
device="platform/icssg1-eth"

# Helper API
err_on_cmd() {                 
        if [ $? != 0 ]; then   
                echo "FAILED: $1"
                echo "HSR OFFload failed in $x 'th try"
                echo "Going Back to dual EMAC mode"
                icssg_disable_hsr_offload
                exit 1;
        fi                     
} 

# Enable HSR Offload mode.

usage() {
        echo "USAGE: $0 <hsr_iface> <on/off> <enable/disable> <ip> <forwarding_method> <cut-thru-que"
        echo ""
        echo "  hsr_iface implies name of the hsr interface to be created i.e. hsr0."
        echo "  On implies hsr offloading is done in hardware, off implies same is done in sw."
        echo "  enables / disables the hsr offload mechanism, this willd delete the hsr iface."
        echo "  ip to be assigned to hsr_iface"
        echo "  forwarding_method implies cut-thru is enabled or store and forward"
        echo "  cut-thru-queue implies the queues on which cut-thru is enabled"
        echo "  Sample cmd - $0 hsr0 on enable 192.168.10.10 cutthru 257"
        echo "  Sample cmd - $0 hsr0 on enable 192.168.10.10"
        echo ""
        exit   
}

icssg_enable_hsr_offload () {

        if [ "$#" != "1" ]
        then
              usage  
        fi

        if [ "$1" != "on" ] && [ "$1" != "off" ]
        then
                usage
        fi

        # Enable all offloads.
        ethtool -K $ifa hsr-fwd-offload $1
        ethtool -K $ifa hsr-dup-offload $1
        ethtool -K $ifa hsr-tag-ins-offload $1
        ethtool -K $ifa hsr-tag-rm-offload $1
        ethtool -K $ifb hsr-fwd-offload $1
        ethtool -K $ifb hsr-dup-offload $1
        ethtool -K $ifb hsr-tag-ins-offload $1
        ethtool -K $ifb hsr-tag-rm-offload $1
        ethtool -k $ifa | grep hsr
        ethtool -k $ifb | grep hsr

        sleep 2

        ip link set dev $ifa address $mac
        ip link set dev $ifb address $mac

        if [[ "$forwarding" == "cutthru" ]]; then
                # Enable cut-thru
                echo "Enabling cutthru $cutthruq"
                devlink dev param set platform/icssg1-eth name cut_thru value $cutthruq cmode runtime
        else 
                echo "not enabling cutthru"
        fi

        ip link add name $if type hsr slave1 $ifa slave2 $ifb supervision 45 version 1

        sleep 3

        ip addr add $ip/24 dev $if
        ip link set $if up

        #show cut-through properties                                                                
        devlink dev param show

}

icssg_disable_hsr_offload () {
        ip link set $if down
        sleep 1
        ip link delete $if  2> /dev/null
        sleep 1
}

if [[ "$2" != "on" ]] && [[ "$2" != "off" ]]; then
        echo "second if"
        usage
fi

if [[ "$3" != "enable" ]] && [[ "$3" != "disable" ]]; then
        echo "third if"
        usage
fi

# Test starts
echo "ip=$ip"
echo "if=$if"
echo "mac=$mac"
echo "slave-a=$ifa"
echo "slave-b=$ifb"
echo "device=$device"
echo "hw_offload=$2"
echo "forwarding_method=$forwarding"

if [[ "$3" == "enable" ]]; then
        icssg_enable_hsr_offload $2
else
        icssg_disable_hsr_offload
fi

我还注意到,在您的测试序列（包括禁用网络 systemd 服务）之前,eth1 和 eth2 接口在运行脚本之前未启用/启动。 也许这可能是您观察 IRQ 问题的原因、如您所述。

该脚本中有关如何启用 HSR 卸载 PRU 的一些更改。 特别是关于在 SDK 9.X 上打开 hsr0 之前打开 eth1 和 eth2。  在 SDK 11.X 上、我们启动了 hsr0。 你知道是否有任何原因吗?  [/报价]

我认为 SDK 11.x 上的变化是、eth1 和 eth2 接口不是显式启动 eth1 和 eth2 接口、而是在运行脚本之前保持 eth1 和 eth2 接口。

[引述 userid=“554501" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1530862/processor-sdk-am64x-duplicate-packets-are-not-removed-with-hsr-pru-firmware/5888683 #5888683“]

-如果打开 eth1 和 eth2 然后打开 hsr0 （如建议的 SDK 9.X ）, HSR 接口会接收数据包,并 根据 IRQ 删除 HSR 重复数据包。 =>确定

-如果我们为 eth1 和 eth2 设置 ethtool 100Mbps 链路速度+ 将 eth1 和 eth2 调到 hsr0 （如建议的 SDK 9.X ）, HSR 接口会接收数据包,并 根据 IRQ 删除 HSR 重复数据包。 ==> Ko（对我来说，使用 ethtool 设置接口链路速度时不应发生这种情况，您是否可以重现此情况？）

[/报价]

您能解释一下这两种情况之间的主要区别吗？ 这里的第一种情况是使用默认的 1Gbps 链路速度吗？ 在第二种情况下、您是否描述了您在 eth1 和 eth2 上都看到 IRQ 计数？

-如果打开 eth1 和 eth2、则打开 hsr0 （如 SDK 9.X）、然后关闭+打开 eth1 和 eth2、则 不会根据 IRQ 删除 HSR 重复数据包。  => Ko（对我来说，重新启动 PRU_ICSSG 固件时不应该发生这种情况、您是否可以重现此问题？ )

我将不得不在下周回到办公室时尝试这种方法。

-道林

[/quote]

尊敬的 Daolin：  

感谢您的快速回答。  

- 测试 1： 如果先将 eth1 和 eth2 调到 hsr0 （按照建议的 SDK 9.X）、HSR 接口会接收数据包、并 根据 IRQ 删除 HSR 重复数据包。 =>确定

- 测试 2： 如果我们为 eth1 和 eth2 设置 ethtool 100Mbps 链路速度+ 将 eth1 和 eth2 设置为 hsr0 （根据建议的 SDK 9.X）、则 HSR 接口会接收数据包、并 根据 IRQ 删除 HSR 重复数据包。 ==> Ko（对我来说，使用 ethtool 设置接口链路速度时不应发生这种情况，您是否可以重现此情况？）

您能解释一下这两种情况之间的主要区别吗？ 这里的第一种情况是使用默认的 1Gbps 链路速度吗？ 在第二种情况下、您是否描述了您在 eth1 和 eth2 上都看到 IRQ 计数？

是的、确定。 TEST1 和 TEST2 之间的区别在于测试 2、我们使用以下命令手动设置 100 Mbps 链路速度。

对于 TEST1、我们使用 RedBox Hirshman 作为发送器的 100 Mbps 链路速度 因此、AM64x (Dut) 在自动协商时需要 100Mbps 的链路速度

对于 TEST2、我们正在使用 AM64x 作为发送方 、我们必须在 DUT 端设置 100 Mbps 的链路速度、以强制实现 100 Mbps 的链路速度。  

ethtool -s eth1 speed 100 duplex full
ethtool -s eth2 speed 100 duplex full

由于我们的一些电路板支持 1000Mbps 链路速度、因此我们必须使用这些命令来设置为 100Mbps 链路速度。  

-如果打开 eth1 和 eth2、然后打开 hsr0 （如 SDK 9.X）、然后关闭+打开 eth1 和 eth2、 则不会根据 IRQ 删除 HSR 重复的数据包。  => Ko（对我来说，在重新启动 PRU_ICSSG 固件时不应该发生这种情况，是否可以在您这边重现此情况？）

我将不得不在下周回到办公室时尝试这种方法。

非常感谢。  

-天一

您好、天一：  

是的、确定。 TEST1 和 TEST2 之间的区别在于测试 2、我们使用以下命令手动设置 100 Mbps 链路速度。

对于 TEST1、我们使用 RedBox Hirshman 作为发送器的 100 Mbps 链路速度 因此、AM64x (Dut) 在自动协商时需要 100Mbps 的链路速度

对于 TEST2、我们正在使用 AM64x 作为发送方 、我们必须在 DUT 端设置 100 Mbps 的链路速度、以强制实现 100 Mbps 的链路速度。  

感谢您解释的不同之处在于手动设置 100Mbps 链路速度。 在 TEST2 过程中、您是否手动配置了 100Mbps 链路速度 规范 eth1 和 eth2 接口？  

我需要研究使用自动协商来设置链路速度与手动配置链路速度之间的主要区别、我感谢您在研究过程中耐心等待。

-道林

尊敬的 Daolin：  

感谢您的快速回答。 是的、我确实会在启动 eth1 和 eth2 之前手动配置 100Mbps 链路速度  

-天一

您好、天一：  

感谢您的快速回答。 是的、我确实在启动 eth1 和 eth2 之前手动配置 100Mbps 链路速度 

感谢您的确认。

-如果打开 eth1 和 eth2、则打开 hsr0 （如 SDK 9.X）、然后关闭+打开 eth1 和 eth2、则 不会根据 IRQ 删除 HSR 重复数据包。  => Ko（对我来说，重新启动 PRU_ICSSG 固件时不应该发生这种情况、您是否可以重现此问题？ )

如昨天调用中所述、对于此问题、作为健全性检查、您是否可以在关闭并备份 eth1 和 eth2 步骤后尝试重新设置 HSR 接口、以查看这是否会导致正确的行为？ 当我回到办公室时、我会尝试进行同样的测试。

-道林

尊敬的 Daolin：

天一在度假,我会尝试在我的假期之前这样做... 我希望问题在这之前不会被锁定

您好、Milan、  

不用担心、只有最旧的响应时间超过 30 天时、线程才会被锁定。 如果它被锁定、我也可以解锁它、我将观察/跟踪此主题。

-道林

您好 Milan/Tian、

我花了一些时间研究这个。 由于 HSR 固件和 Linux 驱动程序最近进行了几项更改来支持这一点、因此我必须改用最新的 SDK 11.1 进行测试。 在此 SDK 之上、还需要应用一个 ICSSG Linux 驱动程序补丁系列来修复 ICSSG 缓冲区分配。 此补丁系列未集成到 SDK 11.1 中、因为它在生成到 SDK 11.1 之前经过了流式传输。 变更详情如下。

SDK 11.1 中应已包含的更改：

• https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/?h=ti-linux-firmware&id=29d948b63a48ec4ff7883d2e246dfb7b6c8153aa 

• https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/net/ethernet/ti/icssg?h=ti-linux-6.12.y&id=7d326261bb2afd77f3fe378e3d42e1c595bc8206 

需要在 SDK 11.1 之上应用的更改：

• 我应用的确切补丁： e2e.ti.com/.../tiL6.12_2D00_v2_2D00_PENDING_2D00_net_2D00_ti_2D00_icssg_2D00_prueth_2D00_Fix_2D00_buffer_2D00_allocation_2D00_for_2D00_ICSSG_2800_1_2900_.patch
• 有关此补丁的更多详细信息： https://lore.kernel.org/all/20250717094220.546388-1-h-mittal1@ti.com/ 

我发现,在 100 米 ping 只适用于特定的序列。 有关详细的序列步骤、请参阅下文。 下面的第二个序列是否适用于您？  

1.使用以下序列时、ping 在 100m 时失败：

1. 在 eth1 和 eth2 上设置 100M
2. 如果尚未启动 eth 接口、请将其调出
3. 设置 HSR 卸载+直通
4. 从 EVM1 到 EVM3 ping

2.当使用不同的序列时, ping 在 100M 通过:

1. 如果尚未启动 eth 接口、请确保其已启动
2. 设置 HSR 卸载+直通
3. 在 eth1 和 eth2 上设置 100M
4. 将 EVM1 ping 至 EVM3

使用我上述的权变措施序列、我再次尝试以 100Mbps 速率进行测试、但我仍然看到、在从 EVM1 ping EVM3 期间、IRQ 计数似乎一次仅在一个端口上增加、这似乎仍然是正确的行为？ 如果我对这里有什么误解、请告诉我。

EVM1 日志： https://gist.github.com/dao-qiu/e9be1f21852f022716bed997c1af6d95

EVM2 日志： https://gist.github.com/dao-qiu/4797213cf81ba6764c4ddc7b4fffc58d

EVM3 日志： https://gist.github.com/dao-qiu/634e8b60d51a5c08526ca9ba58e70332

-道林

您好、Daolin、  

感谢您的快速回答。  

2.由于 100Mbps ping 问题、我以 1Gbps 线路速率测试了此用例（我保持网络服务已启用）、我看到、即使在 HSR 接口已设置后、在 HSR 环形设置中关闭并备份所有 3 个 EVM 上的 eth1 和 eth2 接口、在从 EVM1 到 EVM3 ping 过程中、IRQ 计数似乎一次仅在一个端口上增加、 哪些似乎是预期行为？ 我通过在执行 ping 期间转储 icssg /proc/interrupts 并检查在 ping 期间哪些计数器在递增来进行此检查。 这里有什么我遗漏的吗？ 或者、这种行为仅在 100Mbps 线路速率下可以观察到？ 如果是这样、在 ping 故障问题的情况下、如何以 100Mbps 测试此情况？

您是对的、预期的行为是一次只在一个端口上增加。 我实际上仅在 100Mbps 链路速度下进行测试。 我可以使用配置为 100Mbps 链路速度的 Hirshman RedBox 来重现此问题。 通过自动协商、DUT 会自动获得 100Mbps 链路速度。 （因此，我不必手动设置到 DUT 的 100Mbps 链路速度）

感谢您的帮助和分享不同的修补程序。

我需要与内部团队核实有关此变通办法的信息、并尽快回来。  

-天一

尊敬的 Daolin：  

是否可以在上应用上述修补程序 SDK 11.00.09.04（2025 年 4 月 4 日）  要查找类似的结果? （目前，我们不确定是基于 SDK 11.00 还是 11.01。）  

此外,我在日志上看到,当应用补丁+ SDK 11.01 时,似乎第二个错误不再存在:  

一方

发送器设置为 100 Mbps 链接速度

1：在 DUT 上启动 HSR 脚本  

2：向下按 DUT 的 eth1 和 eth2  

3：上 DUT 的 eth1 和 eth2

4：使用 cat /proc/interrupts、只有一个计数器递增、  

您能否证实我的理解？  

感谢您抽出宝贵时间

-天一  

您好、天一：  

是否可以在上应用上述修补程序 SDK 11.00.09.04（2025 年 4 月 4 日）  查找类似结果

当我之前这样做并在 SDK 11.0 的顶部应用补丁时、我注意到 eth1 和 eth2 接口根本不显示（即使我选中了 ifconfig -a）。 我认为在 SDK 11.0 中、它可能缺少读取新 HSR 固件所需的一些更改、这些固件现在命名为“ am64x-“  而不是  “am65x-"。“。 我得到的建议是改用最新的 SDK 映像。

我所做的是在 HSR 环路中使用 3-EVM 设置进行测试、而不是在 2-EVM 设置中进行测试。 EVM1（发送器）<--> EVM2（交换机/桥接器）<--> EVM3（目标）

1. 如果尚未启动 eth 接口、请确保其已启动
2. 设置 HSR 卸载+直通
3. 使用 ethtool 在 eth1 和 eth2 上设置 100m
4. 将 EVM1（发送方）ping EVM3（目标）并检查无数据包丢失
5. 在具有 IP 链路设置 DEV 的 EVM1 上关闭并恢复 eth1 和 eth2 向下/向上
6. 再次将 EVM1（发送方）ping EVM3（目标）
7. 在 EVM3（目标）上检查 cat /proc/interrupts、并查看 ping 过程中、IRQ 计数似乎一次仅在一个端口上增加

我发现、100M ping 仅适用于特定序列。 有关详细的序列步骤、请参阅下文。 下面的第二个序列是否适用于您？  [/报价]

我只是想检查一下、该解决方法是否适合您？

-道林

尊敬的 Daolin：

感谢您的快速回答。 我需要与内部团队确认。 由于目前我们基于 SDK 11.0、因此如果我们要使用您的解决方法、我们可能需要应用 11.0 至 11.1 范围内的部分/所有补丁内核+ ti-PRU 固件。 我需要仔细检查才能确定。

感谢您的理解

天一  

您好、天一：  

没问题、我将等待您的答复。

-道林

尊敬的 Daolin：  

我刚刚收到了内部团队的反馈。 虽然该权变措施可用作临时解决方案、但最好实现此错误的修复。 您是否有修复程序可用的预计时间线？

-天一  

您好、天一：  

虽然变通办法可以作为临时解决方案、但最好实施此错误的修复。 您是否有修复程序可用的预计时间线？

感谢您继续回答我的问题。 目前、虽然我能够重现 100M ping 问题并已报告、但 HSR 固件团队尚未能够重现该问题。 一旦能够复制问题并缩小根本原因范围、我们应该能够提供修复的时间表。 我想问你们这方面要求的时间安排是什么？  

也许这是清楚的,但通过检查一点细节日志,操作“关闭并备份 eth1 和 eth2 的 EVM1 与 IP link set dev 下电/上电“、应在接收器 EVM3 侧完成以重现错误。  [/报价]

是的、我只在 EVM1 上关闭/打开了 eth1 和 eth2 接口。 我将尝试通过在星期一上的 EVM3（接收器端）上打开/打开 eth1 和 eth2 接口进行重新测试、并告知您是否可以重现问题。 仔细检查一下、是仅是接收器需要关闭/打开接口、还是所有 EVM？

如果我没有通过星期二回复、请 Ping 此主题

-道林

您好、Daolin、  

感谢您的快速回答。 关于截止日期、理想情况下、此错误将在 2025 年 8 月底/9 月初固定。

是的、我只在 EVM1 上关闭/打开了 eth1 和 eth2 接口。 我将尝试通过在星期一上的 EVM3（接收器端）上打开/打开 eth1 和 eth2 接口进行重新测试、并告知您是否可以重现问题。 仔细检查一下、是仅是接收器需要关闭/打开接口、还是所有 EVM？

我对所有 EVM (EVM1、EVM2 和 EVM3) 都是如此、因为我们正在仿真接收器、转发器和发送器上重新启动 PRU 固件的过程。

-天一  

您好、Daolin、  

如前所述、SDK 版本 11.00.09.04 和 11.1 之间的 PRU_ICSSG 固件和 Linux 内核有几处变化。 您知道修复程序是应用于 SDK 11.1 还是 11.00 版？

-天一

您好、天一：  

正如您前面提到的、在 SDK 版本 11.00.09.04 和 11.1 之间、PRU_ICSSG 固件和 Linux 内核有几处更改。 您知道修复程序是应用于 SDK 11.1 还是 11.00 版？

由于 SDK 11.1 和 11.00 已经公开发布、因此任何新的修复通常都将在 git.ti.com 上的 ti-linux-6.12.y-cicd 分支上进行（并且在通过一些内部测试后，更改/修复会使其进入 ti-linux-6.12.y 分支）。 由于这些更改/修复是在 SDK 11.00 和 SDK 11.1 发布之后进行的、因此通常需要通过重新编译内核和模块来手动应用更改。 稍后、我相信它们将被合并到下一个 SDK 版本 SDK 11.2 中。 我的理解是、SDK 11.2 直到今年底才会发布（具体发布日期可能会发生变化）。

过去、我们为您的团队所做的工作要么提供一些补丁修复、要么引导您完成 ti-linux-6.12.y-cicd 分支上的特定提交。 正如我们所注意到的、这种方法很难跟踪软件版本上确切应用的内容。 此外、每当我们解决问题时、我们通常会尝试在最新的 SDK 上重现问题、而不是尝试在旧的 SDK 上修复、因为有时旧 SDK 和最新 SDK 之间的更改可能已经修复了一些问题。

感谢您的快速回答。 关于截止日期、理想情况下、此错误将在 2025 年 8 月底/9 月初确定。

感谢您明确说明这一点！  

是的、我只在 EVM1 上关闭/打开了 eth1 和 eth2 接口。 我将尝试在星期一上的 EVM3（接收器端）上下调/上调 eth1 和 eth2 接口进行重新测试、并告诉您是否可以重现该错误。

我说的是所有 EVM (EVM1、EVM2 和 formp4)、因为我们正在仿真接收器、发送器和转发器上重新启动 PRU 固件的过程。

我还能够重现此问题（使用了 100M ping 问题的解决方法）。 我最近了解到、100 米 ping 问题应该得到解决。  https://lore.kernel.org/all/20250731120812.1606839-1-danishanwar@ti.com/ 看起来这个修复程序目前正在尝试获取被接受的上游版本、因此它尚未被退回到我们的 SDK 版本。 我手动应用了链接中指定的更改、它似乎可以解决 100M ping 问题、并且似乎还可以解决 HSR 重复问题。 下面是我的日志：请查看/试用、看看它是否解决了问题。

EVM1： https://gist.github.com/dao-qiu/49c86cebcdcb1d218b5d49992b82e61d 
EVM2： https://gist.github.com/dao-qiu/e02105b88af47e44648b0665a677cad0 
EVM3： https://gist.github.com/dao-qiu/a79dbc4e984a0ec33a5846ac4e348667 

-道林

您好、天一：  

我应用了您在 SDK 11.1 的内核之上共享的补丁。

除了我分享的用于解决 100M ping 问题的闪存外、您是否尝试过在 SDK 11.1 上应用更新的固件？  

是否有可能在您的身边分享一点更多您是如何进行测试的?  

EVM1： https://gist.github.com/dao-qiu/49c86cebcdcb1d218b5d49992b82e61d 
EVM2： https://gist.github.com/dao-qiu/e02105b88af47e44648b0665a677cad0 
EVM3： https://gist.github.com/dao-qiu/a79dbc4e984a0ec33a5846ac4e348667 

产生这些日志输出的步骤是

1. 在环中连接 EVM1 <>EVM2 <>EVM3  
2. 使用与使用的 ethtool 命令相同的 ethtool 命令在 eth1 和 eth2 上设置 100M
3. 确保 eth 接口已启动
4. 设置 HSR 卸载+直通
5. 在 EVM3 上查看/proc/interrupts | grep icssg
6. 从 EVM1 到 EVM3 ping 以验证通信
7. 在 EVM3 上查看/proc/interrupts | grep icssg 以仅在一个 ICSSG 端口上查看增量
8. 在所有 3 个 EVM 上调低 eth1 和 eth2 并重新启动
9. 在 EVM3 上查看/proc/interrupts | grep icssg
10. 从 EVM1 到 EVM3 ping  
11. 在 EVM3 上查看/proc/interrupts | grep icssg 以仅在一个 ICSSG 端口上查看增量

-道林

您好、天一：  

我将尝试使用 100 个 ping 数据包重新运行、看看是否可以看到相同的问题。 今天或明天我会尝试更新您的信息。  

-道林

尊敬的 Daolin：  

是的、确定。 非常感谢！

-天一

您好、天一：  

我最近了解到 100 米 ping 问题应该有一个解决方案。  https://lore.kernel.org/all/20250731120812.1606839-1-danishanwar@ti.com/ 看起来这个修复程序目前正在尝试获取被接受的上游版本,因此它尚未被退回到我们的 SDK 版本。

对延迟深表歉意。 我正在跟踪我之前分享的补丁；正如我提到的、它正在进行上流式传输、因此在那个时间点、它不被上游接受。 我刚刚检查过、似乎已经做了一些更改来解决潜在的副作用（这可能是看门狗 netdev 错误的一个原因）。 此修补程序的最新版本是 https://lore.kernel.org/all/20250805173812.2183161-1-danishanwar@ti.com/。 请注意,它看起来似乎没有完全合并上游,但维护人员看起来已经签核了。

另请注意、我不确定您的 HSR 设置脚本中有哪些内容。 附件是我在 SDK 11.x 上使用的版本 我认为、与 SDK 9.x 上的内核版本相比、内核版本的差异可能会导致设置 HSR 所需的命令不同

我使用了 HSR 设置脚本： https://gist.github.com/dao-qiu/0c93af9d0f1c14a98e3c078d40271dc1 

我对 hsr_setup.sh EVM1 使用了“./EVM hsr1 on enable 192.168.10.10 cutthru 257“（对于其他 EVM 类似）  

关于 Bug2 :向下 eth1 eth2 ,然后向上 eth1 eth2 ,通过使用变通办法,我仍然观察到重复的 HSR 数据包没有被删除。 这是非常 严重 对我们来说,因为我们有一些脚本,可以同时降下 eth1 和 eth2 ,并加上 eth1 和 eth2。 如果不移除 PRU 固件、它将增加额外的延迟、我们无法实现目标延迟性能。[/报价]

感谢您提请我注意此问题。 我正在尝试按照您的建议重新测试更多的数据包（但包括用于修复 100M ping 问题的补丁）。 我们会在今天尽快回来提供结果。  

-道林

更新：

1.我无法在修复 100M ping 的旧版本的补丁上看到相同的 NETDEV 看门狗问题。 应用 100M ping 的更新版本后、我也看不到看门狗问题。 一种建议是使用我在上一次回复中提供的同一个 HSR 设置脚本在您的终端尝试、然后告诉我您是否仍看到看门狗问题？

2.我能够重现 100 个数据包的 HSR 重复问题（也在非直通和 1Gbps 的情况下）,使用修复 100M ping 的最新版本的补丁。 我将在我的团队内部跟踪此问题、看看我们是否可以缩小问题的范围（很可能是为了关闭 PRU 固件并重新加载它们、也许重新加载过程没有正确恢复...）

这是非常 严重 对我们来说,因为我们有一些脚本,可以同时降下 eth1 和 eth2 ,并加上 eth1 和 eth2。 如果不移除 PRU 固件、它将增加额外的延迟、我们无法实现目标延迟性能。[/报价]

出于好奇心、您是否说当加载 PRU 固件时、它会增加以太网数据包的额外延迟？

-道林

您好、Daolin、  

感谢您的解释。  

对于看门狗问题、我将使用提供的脚本进行尝试。  

第二点,对不起的失败者,这是不清楚的,在我的身边,  

因为内核必须处理 2 个数据包、而不是 1 个数据包。 我观察到、在对系统施加压力或在 DUT 上有多个数据流时、会出现一些额外的延迟。

示例：  

- 3 个没有实时数据包的流  

-一个实时数据包流。  

您是否有解决此问题的预计时间表？  

-天一  

您好、天一：  

对延迟回复表示歉意。

您是否有解决此问题的预计时间表？  [/报价]

我正在尝试让内部软件团队能够复制问题、以便他们可以帮助缩小修复范围。 我们不会有一个修复的时间表,直到他们可以缩小根本原因. 可以向你保证、我们正在努力为此紧急努力。 明天我会告诉您最新情况。

、因为内核必须处理 2 个数据包而不是一个数据包。 我观察到在对系统施加压力或在 DUT 上有多个流时会有一些额外的延迟。

我在这里可能还有点困惑。 我想我知道、当系统承受应力或 DUT 上有多个流时、会导致一些额外的延迟、但我不完全了解卸载 PRU 固件有何帮助？

-道林

[/quote]

更新：

我们有一个可能的修复,我正在测试. 有一些我需要内部验证的附加项目、在我获得一些其他详细信息并验证修复工作之后、我将与您分享。

-道林

尊敬的 Daolin：  

很抱歉、延迟的回复。 根据我的理解、删除重复数据包由 PRU 处理、并不会影响 CPU。 您能否确认我的理解是否正确？

-天一  

好的、感谢您的分享。 这是一个好消息！ 此修复是否在 PRU 固件或/和内核中？  

您好、天一：  

感谢您的分享。 这是一个好消息！ 此修复是否在 PRU 固件或/和内核中？  [/报价]

该修复程序位于 Linux 内核驱动程序侧；您可以在此处找到补丁/详细信息： https://lore.kernel.org/all/20250814105106.1491871-1-danishanwar@ti.com/。 请尝试测试此补丁、如果您发现问题、请告知我们。 请注意、此修补程序仍在进行上流处理、因此在接收上游修补程序之前、您不会看到它集成到 git.ti.com 中。

我测试并发现、只要在运行 HSR 设置脚本时没有看到“无法重新启动固件、中止过程“、就应该修复 HSR 重复丢弃问题。 如果您在测试时看到此消息或其他问题、请告知我们。

总之、您需要确保在 SDK 11.1 上应用以下补丁

• https://lore.kernel.org/all/20250814105106.1491871-1-danishanwar@ti.com/ （用于修复 HSR 重复丢弃问题）-最新补丁
• https://lore.kernel.org/all/20250805173812.2183161-1-danishanwar@ti.com/ （修复 100M ping 问题）
• https://lore.kernel.org/all/20250717094220.546388-1-h-mittal1@ti.com/ （与固件更改保持一致）

根据我的理解、删除重复数据包由 PRU 处理、不会影响 CPU。 您能否确认我的理解是否正确？

正确、重复的数据包丢弃应由 HSR PRU 固件处理、因此重复丢弃功能不应承受 CPU 负载。

-道林

[/quote]

尊敬的 Daolin：  

感谢您分享补丁。 我会尝试一下、今天再回来。  

-天一

尊敬的 Daolin：  

一些好消息。  

通过应用提供的三个修补程序、我们不再看到此问题：  

（修复 HSR 重复丢弃问题）-最新补丁

但是、我仍然注意到问题来自： 修复 100M ping 问题  

提醒一下、下面是过程：

-第 1 步: 为发送器和接收器设置 100 Mbps 链接速度：  

ethtool -s eth1 速度 100 双工全速

ethtool -s eth2 速度 100 双工全速

-步骤 2： 为发件人和接收方启用 HSR 脚本：  

第三步: 尝试从发送器 ping 接收器

有关日志的更多信息：

发送方

am64xx-evm login: root
root@am64xx-evm:~# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 16  bytes 1152 (1.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16  bytes 1152 (1.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@am64xx-evm:~# uname -a
Linux am64xx-evm 6.12.29-00424-g56abcc848a46 #1 SMP PREEMPT_RT Wed Aug 20 10:27:15 CEST 2025 aarch6x
root@am64xx-evm:~# ethtool -s eth1 speed 100 duplex full 
peed 100 duplex fullroot@am64xx-evm:~# ethtool -s eth2 speed 100 duplex full
root@am64xx-evm:~# /usr/bin/hsr_offload_script.sh hsr_hw eth1 eth2 192.168.1.1
hsr_hw eth1 eth2 192.168.1.1
ip=192.168.1.1
if=hsr0
mac=70:ff:76:1f:40:90
slave-a=eth1
slave-b=eth2
device=platform/icssg1-eth
hsr-tag-ins-offload: off
hsr-tag-rm-offload: off
hsr-fwd-offload: off
hsr-dup-offload: off
Actual changes:
hsr-tag-ins-offload: on [not requested]
hsr-dup-offload: on
hsr-tag-ins-offload: on
hsr-tag-rm-offload: on
hsr-fwd-offload: on
hsr-dup-offload: on
hsr-tag-ins-offload: off
hsr-tag-rm-offload: off
hsr-fwd-offload: off
hsr-dup-offload: off
Actual changes:
hsr-tag-ins-offload: on [not requested]
hsr-dup-offload: on
hsr-tag-ins-offload: on
hsr-tag-rm-offload: on
hsr-fwd-offload: on
hsr-dup-offload: on
root@am64xx-evm:~# ifconfig
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::72ff:76ff:fe1f:4090  prefixlen 64  scopeid 0x20<link>
        ether 70:ff:76:1f:40:90  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 21  bytes 1816 (1.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::72ff:76ff:fe1f:4090  prefixlen 64  scopeid 0x20<link>
        ether 70:ff:76:1f:40:90  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 18  bytes 1554 (1.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

hsr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1494
        inet 192.168.1.1  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::72ff:76ff:fe1f:4090  prefixlen 64  scopeid 0x20<link>
        ether 70:ff:76:1f:40:90  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11  bytes 826 (826.0 B)
        TX errors 0  dropped 1 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 64  bytes 4608 (4.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 64  bytes 4608 (4.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@am64xx-evm:~# ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10): 56 data bytes
^C
--- 192.168.1.10 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
root@am64xx-evm:~# 

DUT

root@am64xx-evm:~# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 176  bytes 12672 (12.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 176  bytes 12672 (12.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@am64xx-evm:~# ethtool -s eth1 speed 100 duplex full 
peed 100 duplex fullroot@am64xx-evm:~# ethtool -s eth2 speed 100 duplex full
root@am64xx-evm:~# /usr/bin/hsr_offload_script.sh hsr_hw eth1 eth2 192.168.1.10
hsr_hw eth1 eth2 192.168.1.10
ip=192.168.1.10
if=hsr0
mac=70:ff:76:1e:e6:f4
slave-a=eth1
slave-b=eth2
device=platform/icssg1-eth
hsr-tag-ins-offload: off
hsr-tag-rm-offload: off
hsr-fwd-offload: off
hsr-dup-offload: off
Actual changes:
hsr-tag-ins-offload: on [not requested]
hsr-dup-offload: on
hsr-tag-ins-offload: on
hsr-tag-rm-offload: on
hsr-fwd-offload: on
hsr-dup-offload: on
hsr-tag-ins-offload: off
hsr-tag-rm-offload: off
hsr-fwd-offload: off
hsr-dup-offload: off
Actual changes:
hsr-tag-ins-offload: on [not requested]
hsr-dup-offload: on
hsr-tag-ins-offload: on
hsr-tag-rm-offload: on
hsr-fwd-offload: on
hsr-dup-offload: on
root@am64xx-evm:~# 

使用第二个修补程序： https://lore.kernel.org/all/20250805173812.2183161-1-danishanwar@ti.com/ （修复 100 米 ping 问题）、您会希望修复上述错误？  

-天一

您好、天一：  

正如我们讨论的、100M ping 可能无法正常工作、因为在设置 HSR 之前需要启动接口。

我试图获得一些关于为什么此步骤在内部是必要的信息。

我忘记告诉您的一件事是、您是否需要在设置 HSR 之前禁用/关闭接口？

-道林

尊敬的 Daolin：  

我可以与内部团队核实这一问题,并返回给你！  

-天一

天一、  

您还能否在测试中再次检查、看看是否确实需要在修复 100M ping 的 HSR 设置之前启动接口？ 另外、当您说接口已关闭时、我假设这是由于网络服务之前已被禁用？

-道林

我刚刚完成了测试、并且它正常工作。 我已经与内部团队分享了此变通办法。 从最新的讨论中、他们更倾向于解决此问题。  

关于此问题、6.1 内核 Linux 没有此问题。 在接口 eth1 和 eth2 上行时、可能有一些内存初始化？ 如果您没有启用这些接口、则不会为固件分配内存？  

-天一  

尊敬的 Daolin：  

关于如何在启动 HSR 之前合并接口。 在启动 HSR 脚本之前、内部团队希望在不合并接口的情况下使用。 因为在 HSR 脚本之前合并接口时、它会触发一些事件并提醒最终用户接口状态的变化。 因此、它可以触发多个事件。  

向上接口->启动 HSR 脚本（向下接口+向上接口）。 内部团队希望将 这些警报的数量减少到每次电源循环的单个“up"事件“事件。  

没有与此票证相关的任何内容,您知道内核 6.12 的最新 SDK 11.1 是否支持 10M 链路速度 HSR 吗?

您好、天一：  

我刚刚尝试设置 HSR、使 eth1 和 eth2 接口保持关闭状态、我看到了以下消息。 我看不到日志中的最后 5 行显示在您的日志输出中、您是否可以将 HSR 脚本的部分输出重定向到另一个文件？  

root@am64xx-evm:~# ./hsr_setup_v2.sh hsr1 on enable 192.168.10.10 cutthru 257        
ip=192.168.10.10
if=hsr1
mac=70:ff:76:1e:9c:46
slave-a=eth1
slave-b=eth2
device=platform/icssg1-eth
hw_offload=on
forwarding_method=cutthru
Actual changes:
hsr-tag-ins-offload: on [not requested]
hsr-dup-offload: on
Actual changes:
hsr-tag-ins-offload: on [not requested]
hsr-dup-offload: on
hsr-tag-ins-offload: on
hsr-tag-rm-offload: on
hsr-fwd-offload: on
hsr-dup-offload: on
hsr-tag-ins-offload: on
hsr-tag-rm-offload: on
hsr-fwd-offload: on
hsr-dup-offload: on
Enabling cutthru 257
[ 319.457494] icssg-prueth icssg1-eth eth1: timeout waiting for command done
[ 319.467766] icssg-prueth icssg1-eth eth2: timeout waiting for command done
[ 319.467788] icssg-prueth icssg1-eth: Failed to restart the firmwares, aborting the process
[ 322.505828] hsr1: Slave A (eth1) is not up; please bring it up to get a fully working HSR network
[ 322.505857] hsr1: Slave B (eth2) is not up; please bring it up to get a fully working HSR network

我对 HSR 设置脚本输出中的最后 5 行的理解是、也许 ICSSG Linux 驱动程序正在向 PRU_ICSSG 固件发送命令、但固件没有响应、因此会发生超时。 这只是出于猜测、因为我需要在内部获取更多信息、但我认为固件是经过修改的、目的是希望两个接口都必须准备好来加载 HSR 固件。 我们从日志中可以看到、没有输出表明甚至已加载 HSR 固件。 这可能与用于 Kernel 6.1 的固件有所不同。  

与此票证无关、您是否知道采用内核 6.12 的最新 SDK 11.1 是否支持 10M 链路速度 HSR？

我更喜欢将此主题保留在单独的 TT 上、以便将来可以轻松搜索。 但是、为了快速响应、我的印象是您只需将链路速度设置为 10Mbps 即可获得 10Mbps 链路速度 HSR（与 100Mbps 链路速度 HSR 的操作类似）。 您看到的 10Mbps HSR 是否存在问题？

-道林

尊敬的 Daolin：  

关于超时:我会试一下。 通常我需要做 dmesg 来获得这些消息。  

关于 10Mbps 链路速度、内部团队希望具有 10Mbps 链路速度或 100Mbps 链路速度。 从 6.1 迁移到 6.12 Linux 时、您是否遇到了任何问题？  

-天一