[参考译文] WL1837MOD：网状网络中的大 Toffset、读取/sys/kernel/debug/ieee80211/phy0/netdev：wlan0_mesh/TSF 时内核 oops

您好、Peter、

您能否描述一下您正在使用的内核和 wpa_supplicant 版本？

您是否有关于 您的问题的其他详细信息？ 是什么开始的？ 您连接了哪些设备等？ 您能否提供问题日志示例？

内核的许多版本都会发生崩溃：

* 5.4.47 与您的贴片

* 5.10.72 与您的补丁

* 5.15.71 与您的补丁

* 6.6.52 的修补程序从 6.10 回退

已使用您的 wpa_supplicant 版本以及上行 2.10 和 2.11。

回溯：

/sys/kernel/debug/ieee80211/phy0/netdev:wlan0# cat tsf
[  182.282540] BUG: scheduling while atomic: cat/269/0x00000002
[  182.288304] Modules linked in: cts wlcore_sdio wl18xx wlcore mac80211 cfg80211
[  182.295785] CPU: 0 PID: 269 Comm: cat Tainted: G        W          6.6.52-g0cdede7dcaea #1
[  182.304695] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[  182.310902]  unwind_backtrace from show_stack+0x10/0x14
[  182.316188]  show_stack from dump_stack_lvl+0x40/0x4c
[  182.321293]  dump_stack_lvl from __schedule_bug+0x54/0x68
[  182.326758]  __schedule_bug from __schedule+0x5ac/0x728
[  182.332030]  __schedule from schedule+0x5c/0xb8
[  182.336593]  schedule from schedule_hrtimeout_range_clock+0x10c/0x184
[  182.343074]  schedule_hrtimeout_range_clock from schedule_hrtimeout_range+0x1c/0x24
[  182.350780]  schedule_hrtimeout_range from usleep_range_state+0x5c/0x88
[  182.357438]  usleep_range_state from sdhci_start_signal_voltage_switch+0xc4/0x2c0
[  182.364971]  sdhci_start_signal_voltage_switch from sdhci_runtime_resume_host+0x7c/0x268
[  182.373106]  sdhci_runtime_resume_host from sdhci_esdhc_runtime_resume+0x168/0x1a0
[  182.380727]  sdhci_esdhc_runtime_resume from __rpm_callback+0x3c/0x168
[  182.387315]  __rpm_callback from rpm_callback+0x28/0x54
[  182.392590]  rpm_callback from rpm_resume+0x438/0x5ec
[  182.397690]  rpm_resume from __pm_runtime_resume+0x34/0x6c
[  182.403226]  __pm_runtime_resume from __mmc_claim_host+0x1a8/0x1f4
[  182.409460]  __mmc_claim_host from wl12xx_sdio_raw_write+0x4c/0x15c [wlcore_sdio]
[  182.417019]  wl12xx_sdio_raw_write [wlcore_sdio] from wlcore_runtime_resume+0xc8/0x218 [wlcore]
[  182.426200]  wlcore_runtime_resume [wlcore] from __rpm_callback+0x3c/0x168
[  182.433441]  __rpm_callback from rpm_callback+0x28/0x54
[  182.438729]  rpm_callback from rpm_resume+0x438/0x5ec
[  182.443835]  rpm_resume from __pm_runtime_resume+0x34/0x6c
[  182.449375]  __pm_runtime_resume from wl1271_op_get_tsf+0x70/0x140 [wlcore]
[  182.456685]  wl1271_op_get_tsf [wlcore] from ieee80211_if_fmt_tsf+0x1c/0x44 [mac80211]
[  182.465943]  ieee80211_if_fmt_tsf [mac80211] from ieee80211_if_read+0x58/0xb4 [mac80211]
[  182.475359]  ieee80211_if_read [mac80211] from ieee80211_if_read_tsf+0x1c/0x24 [mac80211]
[  182.484764]  ieee80211_if_read_tsf [mac80211] from full_proxy_read+0x54/0x84
[  182.492486]  full_proxy_read from vfs_read+0x90/0x288
[  182.497592]  vfs_read from ksys_read+0x70/0xf0
[  182.502075]  ksys_read from ret_fast_syscall+0x0/0x64

# iw dev wlan0_mesh scan | grep -A 2 4c:3b:6c:00:91:46
BSS 4c:3b:6c:00:91:46(on wlan0_mesh)
	last seen: 106526.103s [boottime]
	TSF: 5579972760 usec (0d, 01:32:59)
# 
# 
# iw dev wlan0_mesh scan | grep -A 2 4c:3b:6c:00:91:46
BSS 4c:3b:6c:00:91:46(on wlan0_mesh)
	last seen: 106694.113s [boottime]
	TSF: 5388683619 usec (0d, 01:29:48)
# 
# iw dev wlan0_mesh scan | grep -A 2 4c:3b:6c:00:91:46
BSS 4c:3b:6c:00:91:46(on wlan0_mesh)
	last seen: 106912.010s [boottime]
	TSF: 5965877904 usec (0d, 01:39:25)
# 
# 
# iw dev wlan0_mesh scan | grep -A 2 4c:3b:6c:00:91:46
BSS 4c:3b:6c:00:91:46(on wlan0_mesh)
	last seen: 107040.577s [boottime]
	TSF: 4952969548 usec (0d, 01:22:32)

您好、Peter：

谢谢您的提问。 并且您使用的是最新的 FW 8.9.1.2、对吧？

您能描述一下网状网络吗？ 正在使用哪些节点？ 它们都是 wl1837MOD 吗？

是的、固件  8.9.1.0.2.所有节点均为基于 i.IMX6ULL 且具有定制嵌入式系统的充电站。 都使用 WL1837MOD。 一个节点将网状网络桥接至以太网。  

本主题/问题实际上涵盖了两个问题：

1)“猫 TSF“崩溃

2) 稳定性问题最可能是由不良 Toffset 引起的。

起初我以为这些是相关的,但现在我不这么认为。  

第二个问题是 最重要的问题。 此问题仅在具有固件的 Linux 6.6 上出现  8.9.1.0.2.我在具有固件的 Linux 5.15.71 上没有看到它  8.9.1.0.0。在信标中接收/解码 TSF 时间戳时出现问题；运行数小时后。

问题也出现在：

* 5.15.71（带网络补丁）和固件 8.9.1.0.2

* 6.6.52 （带网络补丁）和固件 8.9.1.0.0

* 6.6.52 （带网络补丁）和固件 8.9.1.0.2

我现在编写了一个脚本、用于检查“iw scan“输出中的 TSF：

#!/usr/bin/python3
"Check TSF in iw scan"

import os
import time
import random
import subprocess

def main():
    "Main"
    # Indexed on MAC, contains last TSF
    uptime = subprocess.run(["uptime"], text=True, stdout=subprocess.PIPE, check=True)
    print(f"Uptime: {uptime.stdout.strip()}")

    wilink = subprocess.run(["strings", "/lib/firmware/ti-connectivity/wl18xx-fw-4.bin"],
                            text=True, stdout=subprocess.PIPE, check=True)
    firmware = []
    for line in wilink.stdout.splitlines():
        if line.startswith("FRev "):
            firmware.append(line.split()[1])
    firmware = "/".join(firmware)
    print(f"Wilink firmware: {firmware}")

    uname = " ".join(os.uname())
    print(f"Scanning on {uname}")
    nodes = {}

    for dummy in range(10):
        found = set()
        time.sleep(random.randrange(1, 5))
        try:
            proc = subprocess.run(["iw", "dev", "wlan0_mesh", "scan"],
                                  text=True, stdout=subprocess.PIPE, check=True)
        except subprocess.CalledProcessError:
            continue
        for line in proc.stdout.splitlines():
            if line.startswith("BSS "):
                dummy, mac_etc  = line.split(maxsplit=1)
                mac, dummy = mac_etc.split("(", maxsplit=1)
                mac = mac.lower()
                if mac in found:
                    print(f"{mac}: appearing multiple times")
                found.add(mac)
            elif line.startswith("\tTSF:"):
                dummy, tsf, dummy = line.split(maxsplit=2)
                tsf = int(tsf)
                if nodes.get(mac):
                    diff = tsf - nodes[mac]
                    if not diff >= 0:
                        print(f"{mac}: TSF {tsf} < {nodes[mac]}, backwards")
                    #if diff > 30000000:
                    #    print(f"{mac}: TSF {tsf} > {nodes[mac]} by > 30 s")
                nodes[mac] = tsf
        print(f"Found {len(found)} BSS")

try:
    main()
except KeyboardInterrupt:
    pass

它表明、即使在采用所有 WiLink 补丁的 4.19.38 上、问题也仍然存在。 示例：

root@4C3B6C00BC00:~# ./checktsf.py 
Uptime: 10:12:11 up 1 min,  load average: 1.54, 0.63, 0.23
Wilink firmware: 8.9.1.0.2/8.2.0.0.246
Scanning on Linux 4C3B6C00BC00 4.19.38-27 #1 SMP PREEMPT Mon Jan 12 09:41:52 UTC 2026 armv7l
Found 18 BSS
4c:3b:6c:00:21:56: appearing multiple times
Found 22 BSS
4c:3b:6c:00:21:56: TSF 33973783969 < 33978566736, backwards
4c:3b:6c:00:91:a6: TSF 149390646957 < 245954713494, backwards
4c:3b:6c:00:21:56: appearing multiple times
Found 22 BSS
4c:3b:6c:00:21:56: TSF 33973783969 < 33983354554, backwards
4c:3b:6c:00:21:56: appearing multiple times
Found 22 BSS
4c:3b:6c:00:21:56: TSF 33973783969 < 33988164512, backwards
4c:3b:6c:00:21:56: appearing multiple times
Found 22 BSS
4c:3b:6c:00:21:56: TSF 33973783969 < 33990942617, backwards
4c:3b:6c:00:21:56: appearing multiple times
Found 22 BSS
4c:3b:6c:00:21:56: TSF 33973783969 < 33993699899, backwards
4c:3b:6c:00:91:a6: TSF 149405783092 < 245969851357, backwards
4c:3b:6c:00:21:56: appearing multiple times

这显然是 RX 端问题。 BSS 出现多次的问题并不总是存在的。 通常、有两个节点具有不稳定的 TSF。 如果重新引导、则会报告另外两个 TSF 不稳定的节点。 示例：

root@4C3B6C00BC00:~# ./checktsf.py 
Uptime: 10:13:06 up 2 min,  load average: 1.12, 0.65, 0.26
Wilink firmware: 8.9.1.0.2/8.2.0.0.246
Scanning on Linux 4C3B6C00BC00 4.19.38-27 #1 SMP PREEMPT Mon Jan 12 09:41:52 UTC 2026 armv7l
Found 22 BSS
4c:3b:6c:00:91:a6: TSF 149438654029 < 246005767341, backwards
Found 22 BSS
Found 22 BSS
4c:3b:6c:00:91:a6: TSF 149444173561 < 178542026880, backwards
4c:3b:6c:12:e8:46: TSF 245725758238 < 247627666553, backwards

另一个有趣的是、这些在“iw scan output“中彼此相邻。  

对此有任何更新？ 导致 TSF 不稳定的原因可能是什么？ 您也能看到吗？

Ping

再次大家好、是否对此问题进行了更新？ 您是否需要任何其他信息进行调查？