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.

[参考译文] 是否可以使用 prueth 获取消息? =>"page_pool_release_retry () Stalled pool shutdown'

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1429213/ok-to-get-messages-using-prueth-page_pool_release_retry-stalled-pool-shutdown

器件型号:AM6442

工具与软件:

大家好!

在使用与 EVM 类似的自定义 AM64X 板时、Linux 内核不稳定。

使用从 TI 配方继承而来的最新 Yocto、 然后再编辑 DTS 对我们来说,事情是非常稳定的。
所以我们正在进行测试、以便在我们升级到这个新的内核版本时、我们能够注意到是否引入了不稳定性。

我正在分享我用于测试的脚本、如果有兴趣、可以帮助重现此脚本。 如果这是一个问题、它似乎与初始化有关。 看起来像是一个竞态条件。

这是一条可怕的消息、对于这个新内核、我只遇到它一次、但它会在您升级和关闭 PRU 以太网接口时发生:

[ 293.313047] rpmsg_PRU virtio0.rpmsg-pru.-1.34:消息长度表已满
[ 293.813048] rpmsg_PRU virtio0.rpmsg-pru.-1.34:消息长度表已满
[ 294.313037] rpmsg_pru virtio0.rpmsg-pru.-1.34:消息长度表已满

当我添加然后多次删除 eth1和 eth2时、仍然会看到这些错误(我们为它们使用 PRU_ICSG0)。 我将使用延迟、这样测试就不会太苛刻。 我正在连接用于测试的程序。

[ 5523.786702] PAGE_POOL_RELEASE_RETRY() STALL POOL SHUTDOWN 28 inflight 5427 sec
[ 5523.786713] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 14 inflight 3323 sec
[ 5523.801594] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 10 inflight 3857 sec
[ 5523.818608] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 11 inflight 4471 sec

这是否需要关注?

运行固件:

30004000.RTU   8      运行 ti-pruss/am65x-sr2-rtu0-prueth-Fw.elf  /bus@f4000/icssg@30000000/RTU@4000
30006000.RTU   10     运行 ti-pruss/am65x-sr2-rtu1-prueth-Fw.elf  /bus@f4000/icssg@30000000/RTU@6000
3000a000.txpru 2      运行 ti-prus/am65x-sr2-txpru0-prueth-Fw.elf /bus@f4000/icssg@300000000000/txpru@a000
3000c000.txpru 3      运行 ti-prus/am65x-sr2-txpru1-prueth-Fw.elf /bus@f4000/icssg@300000000000/txpru@c000
30034000.PRU   7      运行 ti-pruss/am65x-sr2-pru0-prueth-Fw.elf  /bus@f4000/icssg@300000000000/PRU@34000
30038000.PRU   9      运行 ti-pruss/am65x-sr2-pru1-prueth-Fw.elf  /bus@f4000/icssg@30000000000000/PRU@38000


此致。

import os
import time
import subprocess
import json
import threading
import sys

PING_RETRIES = 3
CONFIG_DELAY_UP_SEC = 3
CONFIG_DELAY_DOWN_SEC = 1

def run_command(command):
    return subprocess.run(command, shell=True, capture_output=True, text=True).stdout.strip()

def configure_interface(iface, ip, subnet):
    os.system(f"ifconfig {iface} {ip} netmask {subnet} up")

def deconfigure_interface(iface):
    os.system(f"ifconfig {iface} down")

def ping_test(ip):
    return os.system(f"ping -c {PING_RETRIES} {ip}") == 0

def check_interfaces():
    output = run_command("ip -j a")
    interfaces = json.loads(output)
    return interfaces

def is_interface_up_and_ip_correct(iface, expected_ip):
    interfaces = check_interfaces()
    for interface in interfaces:
        if interface['ifname'] == iface:
            if "UP" in interface['flags']:
                for addr in interface['addr_info']:
                    if addr.get('local') == expected_ip:
                        return True
    return False

def interface_test(iface, config):
    ip1 = config["ip1"]
    ip2 = config["ip2"]
    current_ip = ip1

    while True:
        configure_interface(iface, current_ip, config["subnet"])
        time.sleep(CONFIG_DELAY_UP_SEC)

        if is_interface_up_and_ip_correct(iface, current_ip) and ping_test(config["ping_target"]):
            print(f"{iface} ping success with IP {current_ip}")
        else:
            print(f"{iface} ping failed or not configured correctly with IP {current_ip}")

        deconfigure_interface(iface)
        time.sleep(CONFIG_DELAY_DOWN_SEC)
        current_ip = ip2 if current_ip == ip1 else ip1

def start_interface_in_thread(iface, config):
    thread = threading.Thread(target=interface_test, args=(iface, config))
    thread.start()
    return thread

def main():
    interfaces = {
        "eth1": {
            "ip1": "10.42.1.7",
            "ip2": "10.42.1.8",
            "subnet": "255.255.255.0",
            "ping_target": "10.42.1.1"
        },
        "eth2": {
            "ip1": "10.42.2.8",
            "ip2": "10.42.2.9",
            "subnet": "255.255.255.0",
            "ping_target": "10.42.2.1"
        }
    }

    while True:
        threads = []
        for iface, config in interfaces.items():
            thread = start_interface_in_thread(iface, config)
            threads.append(thread)

        for thread in threads:
            thread.join()  # Wait for all threads to finish before next iteration

if __name__ == "__main__":
    try:
        main()
    except KeyboardInterrupt:
        sys.exit(1)

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

    请注意:

    ifconfig 停止工作后、我发送了断电、并在串行控制台中进行了该说明:

    [24613.377349] page_pool_release_retry() stalled pool shutdown 5 inflight 19862 sec
    [*     ] A stop job is running for Network Configuration (57s / 1min 58s)
    [24613.558122] rpmsg_pru virtio0.rpmsg-pru.-1.34: Message length table is full
    [24613.657809] page_pool_release_retry() stalled pool shutdown 2 inflight 20180 sec
    [24613.689919] page_pool_release_retry() stalled pool shutdown 12 inflight 23021 sec


    重新启动测试时具有更大的延迟。

    更新2:

    Linux 是 Yocto 的6.6.32。 在10秒延迟的情况下也发生了崩溃,用脚本让装置过夜。

    [24458.677764] page_pool_release_retry() stalled pool shutdown 14 inflight 19696 sec
    [24458.798249] page_pool_release_retry() stalled pool shutdown 12 inflight 17158 sec
    [24458.798306] page_pool_release_retry() stalled pool shutdown 14 inflight 19741 sec
    [24458.926216] page_pool_release_retry() stalled pool shutdown 14 inflight 22053 sec

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

    您好、Nelson:

    我想仔细检查你的陈述" 然后再编辑 DTS 对我们来说,事情是非常稳定的"。

    这是否意味着您观察到的这种行为仅在对 devicetre 文件进行更改后才会出现? 如果是、您要对 devicetre 文件进行哪些更改?

    您是否有 TI EVM? 如果是、您是否也能够在 TI EVM 上复制此行为?

    此致、

    Nick

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

    感谢您的回复 Nick。

    >我想仔细检查你的说法"编辑 DTS 之前,事情对我们来说是非常稳定的"。

    编辑 DTS 之前。 但这也是一个新的内核版本,所以我们想从头开始测试,并得到我正在报告的消息。

    我没有 TI EVM。 所有让 EVM 在 Phytec 的 phyboard-am64x 和我们的电路板上为我运行的示例。 我是 Phytec 的董事会。

    我们应该得到一个 TI EVM、以便我们可以尝试... EVM 是否使报告无效?

    此致。

    使用最新的 Yocto 在 Phytec 电路板上进行测试。

    Linux 内核:v6.6.6.6.32-10.00.08 (标签:v6.6.6.32-10.00.08-phy2)
    Yocto:5.0.3 ScarthGap (标签:BSP-Yocto-Ampliphy-AM64x-PD24.1.0)

    [ 1300.781187] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 36 inflight 422 sec
    [ 1300.877177] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 32 inflight 422 sec
    [ 1301.165152] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 36 inflight 845 sec
    [ 1301.261158] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 40 inflight 845 sec
    [1301.410896] remoteproc remoteproc11:为30034000.pru 上电
    [1301.417096] remoteproc remoteproc11:引导固件映像 ti-pruss/am65x-sr2-pru0-prueth-Fw.elf、大小39464
    [ 1301.426832] remoteproc remoteproc11:不支持的资源5.
    [1301.432526] remoteproc remoteproc11:远程处理器30034000.pru 现在已启动
    [1301.439672] remoteproc remoteproc12:为30004000 RTU 供电
    [1301.445666] remoteproc remoteproc12:引导固件映像 ti-pruss/am65x-sr2-rtu0-prueth-Fw.elf、大小为31140
    [1301.455195] remoteproc remoteproc12:远程处理器30004000.RTU 现在已启动
    [1301.46233] remoteproc remoteproc5:为3000a000.txpru 供电
    [1301.468476] remoteproc remoteproc5:引导固件映像 ti-pruss/am65x-sr2-txpru0-prueth-Fw.elf、大小39068
    [1301.478232] remoteproc remoteproc5:远程处理器3000a000.txpru 现已启动
    [ 1301.485787] remoteproc remoteproc9:为30038000.pru 供电
    [1301.491776] remoteproc remoteproc9:引导固件映像 ti-pruss/am65x-sr2-pru1-prueth-Fw.elf、大小为39624
    [1301.501199(1998) remoteproc remoteproc9:不支持的资源5.
    [1301.506789] remoteproc remoteproc9:远程处理器30038000.pru 现已启动
    [1301.513824] remoteproc remoteproc10:为30006000.RTU 供电
    [1301.519835] remoteproc remoteproc10:启动 FW 映像 ti-pruss/am65x-sr2-rtu1-prueth-Fw.elf、大小30380
    [1301.529299] remoteproc remoteproc10:远程处理器30006000.RTU 现在已启动
    [1301.53643] remoteproc remoteproc6:为3000c000.txpru 供电
    [ 1301.542527] remoteproc remoteproc6:引导固件映像 ti-pruss/am65x-sr2-txpru1-prueth-Fw.elf、大小为37556
    [1301.552163] remoteproc remoteproc6:远程处理器3000c000.txpru 现已启动
    [ 1301.560951] pps pps0:新 PPS 源 ptp2
    [1302.925127] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 31在飞行181秒
    [ 1302.989139] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 39 inflight 181 sec
    [1303.245121] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 36 inflight 604 sec
    [1303.341150] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 35在飞行604秒
    [ 1303.629129] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 34在飞行1027秒
    [ 1303.693116] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 38 inflight 1027 sec
    [ 1304.622024] icssg-prueth Ethernet eth2:链路接通- 1Gbps/全-流控制关闭
    [ 1304.653872] icssg-prueth Ethernet eth1:链路接通- 1Gbps/全-流控制关闭
    [ 1305.357111] PAGE_POOL_RELEASE_RETRY () STALLED POOL SHUTDOWN 36帧中362秒
    [ 1305.453102] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 38 inflight 362 sec
    [ 1305.773104] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 36 inflight 785 sec
    [ 1305.869086] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 37在飞行785秒
    [1306.061092] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 30 inflight 1208 sec
    [1306.125089] PAGE_POOL_RELEASE_RETRY () STALL POOL SHUTDOWN 45 inflight 1208 sec

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

    您好、Nelson:

    如果您没有可复制结果的 TI EVM、这不会使您的观察结果无效。 但我们只有 TI EVM、因此如果某件事由硬件问题(或通常是硬件设计的一部分)引起、而您使用的硬件与我们不同、则替换测试结果会变得困难得多。

    1)从快速浏览到测试代码,我不确定我是否理解了逻辑。 看起来您使用一个 IP 地址启动接口、然后将其重新启动、再使用另一个地址重新启动接口?

    2)是否 有必要在 IP 地址之间切换才能看到您所看到的行为? 或者、在以太网端口上仅使用单个 IP 地址、您也会看到相同的行为吗?

    3) 3)请评论您使用的 PRU 以太网端口。 例如、eth1和 eth2是在同一 ICSSG 子系统还是不同的 ICSSG 子系统上?

    4) 4)如果您只有一个以太网端口上下运行、您是否仍能看到该行为、或者是否需要两个以太网端口上下运行来显示该行为?

    此致、

    Nick

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

    您好、Nick、很抱歉耽误您的时间。 我将能够在下周进行更多测试。

    1. 是的,就是这样。 此外、还有*NO*锁定功能、可确保只同时启动或停止一个 ETH。

    2、不需要修改 IP。 我这样做是为了有更大的信心、我正在测试一些有意义的东西。

    3.相同的 ICSSG 子系统(0)。

    4.无法立即测试*,将尽快测试。 很可能在下周。

    此致。