Jetson Orin NX WiFi断连排查：从驱动超时到持久化修复

事情发生在一个很普通的晚上：我拿 Jetson Orin NX 跑完一个模型蒸馏任务，顺手把几个 GB 的权重文件通过网盘客户端往云上慢慢传。开头挺顺利，结果传到将近一半，板子上的 WiFi 突然就没了。浏览器提示断网，右上角网络图标变灰，nmcli里连wlan0都看不见了。更烦的是，重启 NetworkManager、拔插 USB 网卡统统没用，只能整个板子断电重启。这个问题我在 Jetson Orin NX 上至少遇到过三次，每次都是“网盘上传大文件”这个特定场景触发，非常典型的“高吞吐压力下 WiFi 状态机卡死”。这篇文章我把完整的排查思路、应急方案和最终的持久化配置都整理出来，希望能帮到同样被这个坑折磨的人。

这类问题在 Jetson Orin NX 上尤其容易发生，因为它板载的 M.2 WiFi 模块很多用的是 Realtek 方案（比如 RTL8852BE 这一代），在 Ubuntu 20.04/22.04 这类 L4T 镜像里的驱动远没有 Intel 方案那么“省心”。加上 Jetson 本身内存只有 8GB/16GB，跑着模型任务再开网盘上传，资源竞争一激烈，WiFi 驱动就成了最先扛不住的那一个。

1. 问题现场与根因判断

1.1 症状回放：不是简单的“网速慢”，是直接断连失联

先说症状细节。我那次是用浏览器打开网盘网页版，一次选择了多个 GB 级文件上传。上传开始后前十分钟一切正常，网速能顶到路由器协商速率的上限。但大约十几分钟后，先是网速突然掉到几乎为 0，接着浏览器里的网盘页面开始转圈圈，然后整个界面弹出“网络连接已断开”。

这时候用ip addr看网卡状态，无线接口还在，但状态已经不再是UP，也没有拿到 IP。用nmcli查看设备，显示wlan0的状态是unavailable或者直接消失。最夸张的一次，nmcli dev status里连无线网卡都看不到了，像是系统完全不认识这块网卡一样。

这类“设备直接消失”的症状，基本可以排除普通路由器层面的问题。如果只是信号差或者路由器掉线，网卡本身应该还在，最多是disconnected状态。设备从系统总线层面“蒸发”，说明问题出在驱动或者硬件热失控层面。

1.2 为什么偏偏是“大文件上传”触发

很多人第一反应是路由器太弱，但我在多台设备上测试过，只有 Jetson Orin NX 出问题，同一个路由器下手机、笔记本都正常。所以问题大概率出在板子自身。那么为什么大文件上传特别容易触发？我总结三个叠加因素：

第一，持续高吞吐造成驱动超时。大文件上传意味着 WiFi 模块长时间工作在最高速率档位，数据包队列一直是满的。Realtek 驱动的固件和主控之间如果出现某个中断响应延迟到达，就会触发TX timeout，驱动内部状态机一乱，整个连接就废了。

第二，内存压力把驱动进程“饿死”。Jetson Orin NX 的 8GB 版本在跑深度学习任务时内存已经紧张，浏览器渲染网盘页面、文件压缩校验、系统缓存再占一块，一旦触发内存回收或者 OOM Killer，内核里某些驱动依赖的内存分配就会失败。虽然 Realtek 驱动本身运行在内核态，但内存碎片和直接回收也会造成严重的响应延迟。

第三，高频工作状态下的发热积累。M.2 WiFi 模块在持续高功率发射时发热非常明显，而 Jetson 开发者套件的 M.2 插槽位置通常在散热片附近，空气流通并不好。模块过热后要么自动降频（表现为网速断崖式下跌），要么直接驱动 reset，极端情况下固件崩溃，需要完全断电才能恢复。

1.3 硬件与驱动背景：为什么 Jetson 上尤其容易中招

先说结论：Jetson Orin NX 开发套件原生支持的 WiFi 方案因批次和供应商不同而差异很大，常见的主流型号是 Realtek RTL8852BE（WiFi 6 / 802.11ax），也有少量 Intel AX210 或 Broadcom 方案。问题集中爆发在 Realtek 方案上。

这款 RTL8852BE 是 PCIe 接口的 WiFi 6 网卡，Linux 下的驱动是rtw89系列。rtw89驱动本身在普通笔记本上也不算稳定，而 Jetson 平台的 L4T 内核又做了大量 NVIDIA 定制，内核版本和驱动版本的匹配度比通用发行版更敏感。我实测过 JetPack 5.1.2、6.0 等版本，WiFi 模块在大流量下的表现都不理想。而且在 Jetson 上，无线网卡通常由设备树在启动时初始化，驱动无法像 x86 笔记本那样在运行时热插拔，出问题后恢复手段非常有限。

2. 定位根因：三步锁定是驱动崩了还是网络服务挂了

2.1 第一步：确认网卡在系统总线层面是否还存在

遇到 WiFi 断连，第一件事不是重启，而是确认无线网卡硬件是否还“活着”。这一步可以快速区分问题层级：

lspci | grep -i wireless lspci -vnn | grep -i 8852

如果你的无线网卡是 PCIe 接口，那么上面命令会输出类似Network controller: Realtek Semiconductor Co., Ltd. Device 8852这样的内容。看到这个输出，说明硬件至少还在 PCIe 总线上，问题大概率是驱动状态卡死。反之，如果lspci里什么都没有，或者出现了rev ff（表示设备响应异常），那说明硬件层面已经失联，属于驱动 reset 失败或者硬件过热保护触发了。

对于 USB 接口的无线网卡，用lsusb看设备是否还在列表里，判断逻辑同理。这一步一定要在重启任何服务之前做，因为它直接决定你是走“软恢复”还是“断电硬恢复”路线。

2.2 第二步：检查 NetworkManager 是否进入了假死状态

Jetson 的 Ubuntu 桌面版和 L4T 镜像用的网络管理工具基本都是 NetworkManager。它在 WiFi 状态异常时经常会出现“插件假死”——网络接口已经消失了，但 NetworkManager 还在等驱动层事件返回，表现为nmcli命令长时间挂起，或者状态始终停在connecting。

查看状态用这两个命令：

systemctl status NetworkManager journalctl -u NetworkManager -n 100 --no-pager

在日志里，你经常会看到类似dummy (7): carrier now 0或者wlan0: unavailable的记录。如果日志里能看到网卡从available变为unavailable的时刻，那基本能确认是驱动先异常，NetworkManager 只是被动接收到了错误状态。注意，这时候不要急着去systemctl restart NetworkManager，因为如果驱动层已经崩了，重启 NetworkManager 根本无济于事，它查不到网卡就依然会显示unavailable。

2.3 第三步：用 dmesg 找驱动层的关键证据

接下来最关键的一步——查看内核日志。这一步给出的信息最直接：

dmesg | grep -iE "rtw|wlan|ieee80211|firmware|timeout|error" | tail -50

如果你是 Realtek 8852BE 网卡，大概率会看到以下几类典型报错：

• rtw89_pci 0000:01:00.0: tx timeout——驱动在持续高吞吐下没能在规定时间内完成发送队列的清理，触发了超时机制。
• rtw89_8852be: firmware loading failed——固件重载失败，这时候网卡基本就废了。
• ieee80211 phy0: Hardware restart was requested——驱动尝试让网卡硬件重启，但如果固件状态已经崩坏，这个 restart 会失败。
• 还有一类常见的usb disconnect或PCIe link down，说明硬件过热或者供电异常。

如果看到firmware loading failed或者Hardware restart was requested后面的日志显示 restart 失败，那就老老实实断电硬恢复吧。软件层的modprobe和 NetworkManager 重启都救不回来了。如果只是tx timeout，日志后面没有跟着更严重的报错，那么大概率可以通过卸载再加载驱动的方式恢复。

3. 分步解决：从应急恢复到持久化修复

3.1 应急恢复三板斧：卸载重载驱动、PCIe 重扫、全局重启

我把应急恢复方案按“从轻到重”排好，实际执行时按顺序来，每一步尝试完就检测一次网卡是否恢复。

第一板斧，卸载再加载驱动模块。这一步在tx timeout但硬件没彻底死掉时很管用：

# 找到当前加载的 rtw89 相关模块 lsmod | grep rtw89 # 按依赖顺序卸载 sudo modprobe -r rtw89_pci sudo modprobe -r rtw89_core # 重新加载 sudo modprobe rtw89_pci

注意，Realtek 的模块命名是分层次的：rtw89_core是核心模块，rtw89_pci是 PCIe 接口层，rtw89_8852be是具体芯片模型。如果modprobe -r时报 “module is in use”，先把 NetworkManager 停掉再卸载：

sudo systemctl stop NetworkManager sudo modprobe -r rtw89_pci rtw89_core sudo modprobe rtw89_pci sudo systemctl start NetworkManager

第二板斧，如果卸载重载之后还是看不到设备，尝试对整个 PCIe 总线做一次热重扫。这个方法可以触发内核重新枚举 PCIe 设备，相当于给网卡一次“重新插拔”的机会，而不用真正动硬件：

# 找到网卡的 PCI 地址，通常类似 0000:01:00.0 lspci | grep -i realtek # 将设备从总线上取下 sudo sh -c 'echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove' # 重新扫描整个 PCIe 总线 sudo sh -c 'echo 1 > /sys/bus/pci/rescan'

执行完rescan后等几秒，再lspci看设备是否回来了。回来后一般会自动重新加载驱动，然后nmcli里网卡就会重新出现。

第三板斧，如果 PCIe 重扫也无效，就会遇到我最不想面对的情况：必须断电重启。注意不要用reboot命令，而是把 USB-C 电源完全拔掉再插上，等 10 秒左右再开机。因为 Jetson 的reboot如果是软复位，某些 PCIe 设备和供电状态不会完全掉电，WiFi 模块还是处于过热保护锁死的状态。只有完全断掉电源，让硬件层面做一次彻底重置，才能恢复。

3.2 持久化修复：禁用 WiFi 电源管理

如果你的板子能通过应急恢复手段拉起来，但下次上传大文件还会复发，那就必须改持久化配置了。我试验下来最有效的一项就是禁用 WiFi 电源管理。

Linux 的无线网卡默认默认开启power save模式，也就是在空闲时降低发射功率和采样频率来省电。这功能平时没问题，但在 Jetson Orin NX 上配合 Realtek 驱动，问题非常大——它在省电模式和全速模式之间切换时，状态机处理得不够稳健，频繁切换直接导致驱动超时。

禁用方法有两种：

方式一，命令行直接关闭：

sudo iw dev wlan0 set power_save off

但这种方式重启之后就失效了，不适合作为持久化方案。

方式二，通过udev规则让每次网卡启动时自动关闭：

sudo tee /etc/udev/rules.d/70-wifi-powersave.rules << 'EOF' ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*", RUN+="/usr/bin/iw dev %k set power_save off" EOF

你可能会问，为什么要通过 udev 规则而不是 NetworkManager 的配置？因为 udev 在网络设备出现的瞬间就执行命令，而 NetworkManager 的连接配置文件虽然也有powersave选项，但它的选项值在某些 L4T 版本中不一定能正确传达到 Realtek 驱动的底层。我实测过，直接用 udev 规则最稳定。

如果你用的网卡驱动是rtw89，还可以在驱动参数层面做更彻底的控制。现在拉出驱动的可调参数看看：

ls /sys/module/rtw89_core/parameters/

如果有disable_ps_mode这类参数，直接用modprobe配置：

echo "options rtw89_core disable_ps_mode=1" | sudo tee /etc/modprobe.d/rtw89.conf

然后重新生成 initramfs 使模块参数在开机时就生效：

sudo update-initramfs -c -k $(uname -r)

3.3 调整 NetworkManager 的连接配置

除了电源管理，NetworkManager 对连接参数的处理方式也可能加剧问题。特别是 WiFi 的认证超时时间和 BSS 漫游策略，在大流量场景下会触发一些你认为不该发生的“掉线”。

打开当前 WiFi 连接的配置：

nmcli connection show # 找到你的 WiFi 连接名，比如 "MyWiFi" nmcli connection edit "MyWiFi"

在里面设置以下参数：

set 802-11-wireless.powersave 2 set 802-11-wireless.rate-mgmt default set 802-11-wireless.wake-on-wlan 0 save quit

这里的核心是powersave 2，这个值代表“禁用电源保存”。wake-on-wlan 0是为了防止网卡在低功耗模式下被魔法包唤醒时出错，在 Jetson 这种稳定性要求高的场景下直接关掉最省心。

不要一次改太多参数，每次只改一个，然后长时间压测，确认稳定后再改下一个。这样可以准确定位到底是哪个参数起了决定性作用。

3.4 从资源层面做减法：上传方式与内存优化

驱动层面的配置做完，还要对“大文件上传”这个触发条件做优化。我后来反思了一下，其实很多问题是自己把板子逼得太紧了：一边跑着推理任务，一边用浏览器上传大文件，内存本来就不宽裕。

这里强烈建议一个操作：网盘上传尽量用命令行客户端或者rclone，别用浏览器。浏览器本身就是内存大户，一个页面吃掉 1-2GB 内存太正常了。rclone这类命令行工具内存占用小，而且支持限速、断点续传、重试机制，对嵌入式平台友好得多。举个例子：

rclone copy /data/model.pt mypan:/models/ --transfers 1 --tpslimit 4

配合--bwlimit 50M把上传带宽限制在 50Mbps 左右，这样既能避免占满整个无线链路，也降低了 WiFi 模块发热量。我实测限速之后，断连概率下降了一大截。这里有个心态需要调整：在 Jetson 这种嵌入式平台上，追求无线传输跑满不是好习惯，稳定比速度重要得多。

内存层面也要做检查。上传大文件时用free -h观察内存占用：

free -h

如果发现可用内存长期低于 500MB，就需要上交换空间了。Jetson 的 NVMe SSD 或者好的 TF 卡都能承担 swap 功能：

# 在 NVMe SSD 上创建一个 4GB 的 swapfile，避免磨损 TF 卡 sudo fallocate -l 4G /var/swapfile sudo chmod 600 /var/swapfile sudo mkswap /var/swapfile sudo swapon /var/swapfile # 设置开机自动启用 echo '/var/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

交换空间本身不会直接让 WiFi 变强，但能防止系统在内存压力下触发 OOM Killer 或者让内核的内存分配长时间阻塞。这是一层防守，配合驱动参数调整才构成完整方案。

4. 大流量场景下的可靠配置实战

4.1 连接参数固化

上一步我们改的是单个 Wi-Fi 连接的参数，但如果你经常换网络（比如带着 Jetson 在办公室和家里之间切换），建议把公用的默认连接参数调好。

NetworkManager 支持全局配置，直接把powersave写进/etc/NetworkManager/conf.d/default-wifi-powersave.conf：

[connection-wifi] wifi.powersave = 2

这个配置会作用于所有 WiFi 连接，凡是支持该参数的驱动都会生效，相当于全局兜底。注意，修改后要重启 NetworkManager：

sudo systemctl restart NetworkManager

4.2 固件和驱动的版本确认

在 Jetson 这种 BSP 平台上，驱动版本是否合适，直接影响稳定性。如果你还在用 JetPack 5.x，驱动可能比较旧，Realtek 的很多修复是后补的。用以下命令确认当前的驱动和固件状态：

modinfo rtw89_pci | grep -E "version|filename" dmesg | grep -i rtw89 | head

我没有给“升级到最新内核”这种建议，因为在 Jetson 上自己编译 L4T 内核的代价很高，而且可能破坏 NVIDIA 驱动层的兼容性。正确的做法是：优先确认 NVIDIA 官方发布的最新 JetPack 版本中是否包含了更新的 Realtek 驱动，然后通过 SDK Manager 升级，而不是自己去内核官网拉一个最新内核。

4.3 功耗模式与热量管理

Jetson Orin NX 的功耗模式直接影响到 WiFi 模块的工作环境。默认情况下，开发者套件可能运行在最高性能模式（比如 25W），此时 CPU 和 GPU 满负荷工作，热量通过散热片传导，会让 M.2 插槽附近的温度达到 60°C 以上。

WiFi 模块内部温度超过 75°C 时，很多驱动的固件会有主动保护策略，表现为先降低速率，再断开连接。所以如果你的板子在跑任务的同时还要搞上传下载，建议把功耗模式调整到更保守的档位：

sudo nvpmodel -q # 查看当前模式，比如 MAXN 是最高功耗档

如果对实时性要求不高，可以选择 15W 或者 10W 的档位：

sudo nvpmodel -m 8 # 具体编号以 nvpmodel -q 查询结果为准

这个命令需要小心使用，因为它同时会限制 CPU 和 GPU 的算力。我个人的原则是：如果只是做上传文件这种轻负载场景，就切到低功耗模式；如果是边跑训练边上传，那低功耗模式会拖慢训练速度，此时不如给 WiFi 模块一个独立的辅助散热方式。

4.4 自动监测与断线重连

无论前面的配置做得多完备，开发板这个 WiFi 硬件在极端条件下仍可能偶尔抽风。与其每次自己手动处理，不如写一个 watchdog 脚本，监测到断线后自动走应急恢复流程。

我写了一个基础版的监测脚本，逻辑非常简单：每 30 秒 ping 一次网关，连续 3 次失败就认为网络断了，然后尝试重载驱动和重连：

#!/bin/bash # /usr/local/bin/wifi-watchdog.sh GATEWAY=$(ip route show default | awk '/default/ {print $3; exit}') FAIL_COUNT=0 while true; do if ping -c 1 -W 2 "$GATEWAY" > /dev/null 2>&1; then FAIL_COUNT=0 else FAIL_COUNT=$((FAIL_COUNT + 1)) if [ "$FAIL_COUNT" -ge 3 ]; then # 触发驱动重载 sudo systemctl stop NetworkManager sudo modprobe -r rtw89_pci rtw89_core sleep 2 sudo modprobe rtw89_pci sudo systemctl start NetworkManager SLEEP 10 FAIL_COUNT=0 fi fi sleep 30 done

注意这个脚本里的重载逻辑要依赖具体网卡驱动名，如果你用 Intel AX210，就换成对应的模块名。在 Jetson 上使用 sudo 自动执行时不需要密码，因为默认用户是 nvidia 且带 sudo 免密权限。脚本用 systemd 定时器拉起即可。

不过这个脚本只是应急兜底，不能替代真正的配置校正。如果你的网络环境里网关不允许被 ping（有些路由器默认关闭 ICMP），可以换成检测 DNS 解析：

ping -c 1 -W 2 8.8.8.8

或者直接调用nmcli的connectivity check，看自己的网络环境选择。

5. 常见问题与排查技巧实录

5.1 问题速查表

我把自己和周围朋友遇到过的 Jetson WiFi 问题整理成了速查表，方便你对照排查：

5.2 我踩过的几个坑

第一个坑：不要迷信nmcli dev disconnect和connect。我在第一次遇到问题时，以为只是连接断了，反复执行 disconnect/connect，结果网卡状态始终卡在unavailable。后来查 dmesg 才知道驱动层已经崩了，这时候单纯的连接管理操作是无效的。

第二个坑：重启 NetworkManager 之前一定要先查 dmesg。很多人遇到 WiFi 问题第一反应就是systemctl restart NetworkManager，但在 Jetson 上如果驱动层的错误没解决，重启多少次网络服务都没用。而且频繁重启 NetworkManager 有时会掩盖真实错误日志，导致你回头排查时很难定位根因。

第三个坑：Jetson 的软重启reboot无法恢复硬件锁死。有一次我上传到一半网盘后 WiFi 断了，我以为和电脑一样重启系统就完事，结果reboot起来后 WiFi 依然不可用。后来查 NVIDIA 官方论坛才知道，在 Jetson 上执行reboot时许多 PCIe 外围设备并不会完全断电，必须完全拔掉电源再重新上电。这个信息在很多教程里都没单独提过，我自己吃了不少亏。

第四个坑：udev 规则文件名要按顺序生效。如果你的系统里还有别的网络管理工具（比如wpa_supplicant自启），udev 规则的执行时机可能会被其他服务抢占。写/etc/udev/rules.d/70-wifi-powersave.rules时，这个70数字不是随便写的，它表示比默认规则90更早执行，算是对网卡设置的一个“先手”。

5.3 长期稳定策略：多做减法，少做加法

折腾完这些配置后，我给自己定了几条“Jetson WiFi 使用纪律”：

第一，大文件传输一律用rclone或 AirExplorer 这类命令行/轻客户端，不用浏览器。浏览器上传在嵌入式平台上是个灾难，它不只是吃内存，还会因为页面内部的 JS 大量重试请求，额外制造无意义的网络负载。

第二，传输前检查内存和 CPU 状态。就算要跑模型任务，也尽量错开上传时间，或者给上传任务设置nice级别让它少抢资源。命令行可以用nice -n 19 rclone copy ...降低进程优先级。

第三，定期查看dmesg的 WiFi 相关日志。不要等到断网才想起来，而是每次系统重启后扫一眼：

dmesg | grep -iE "rtw89|wlan0|ieee80211" | tail -20

如果有持续告警在浮动，说明驱动状态已经在恶化，可以在问题爆发前主动重载一次驱动。

6. 最后再分享一点个人经验

这个问题折腾了我将近一周，从最初怀疑路由器、怀疑电源供电、怀疑网线，到最后锁定在 Realtek 驱动与 Jetson 电源管理策略的配合问题上，走了不少弯路。回头总结，最让我受益的经验是：在 Jetson 上排查 WiFi 问题，一定要把“驱动状态检查”放在最前面。因为它不是一台普通笔记本，网络管理栈上面还有一层 NVIDIA 定制的系统组件，逐层排查才能避免无头苍蝇式操作。

还有一个特别值得养成的好习惯——把常用的诊断命令整理成一个小脚本。比如wifi-diag.sh，一键输出lspci、lsusb、nmcli dev status、dmesg过滤、free -h这些关键信息。出了问题，先跑一遍脚本保存现场，再做任何修改。我自己之前就是没记录现场，导致同一个问题每次都要重新查一遍日志，浪费了很多时间。

另外，如果你在社区里搜索到相似问题，别光看“重启就好了”这种答案，要往下面翻一翻，看看有没有人和你一样在 Jetson 加上 Realtek 这个组合下反馈同类问题。很多时候，你遇到的问题不是孤例，而是这个平台组合的已知通病。找到那个讨论帖，把里面的内核参数和驱动版本信息抄下来比对，比你自己从零试错要高效得多。