先说个我上周真实遇到的场景：手头这台 Jetson Orin NX 在跑边缘推理项目，往私有网盘传一个 12GB 的模型压缩包，用的是 rclone 命令行上传，速率稳定在 70MB/s 左右。传输开始才一分多钟，我习惯性地 ssh 进去看一眼进度，结果直接超时。跑到机器跟前一看，板子还在转、风扇满速转，但 WiFi 的状态已经变成 DISCONNECTED，重启 NetworkManager、重新扫描信号，怎么搞都回不去，最后只能硬重启。重启后一切恢复正常，但只要再次用网盘上传大文件，十分钟内必掉线。
这篇文章就是围绕这个故障展开的完整排障记录。如果你是拿 Jetson Orin NX / AGX 做边缘计算开发，用的是 M.2 扩展 WiFi 模块，并且经常要推大文件、跑高吞吐任务的，那这篇内容基本能覆盖你遇到同款问题时的排查思路、应急手段和根治方案。我会把驱动层、电源管理层、射频干扰层的东西都拆开讲一遍。
1. 现象确认与故障边界
1.1 先看典型复现路径
先复盘一下完整的环境和操作步骤，方便对照。我这台 Orin NX 是 16GB 版本，刷的 JetPack 5.1.3（Ubuntu 22.04 LTS，内核 5.10 定制版），网卡是 M.2 Key E 槽上的一块 Realtek RTL8852BE WiFi 6 模组，路由器是 5GHz 频段下开启了 802.11ax 模式。
复现流程非常有规律：
- 开机后系统正常启动，WiFi 能自动连接，ping 网关延迟 1-2ms。
- 用 rclone 或浏览器拖一个大文件到网盘，速率一上来就开始记时。
- 大约 1-5 分钟后，SSH 会话无响应，刷新网页打不开任何页面。
- 走到板子前看，系统活着，
nmcli device status显示 wlan0 为 DISCONNECTED。 - 尝试手动重连，提示 Connection activation failed，扫描信号也报错，表现为整个无线接口“假死”。
关键点在于：这不是简单的“邻居蹭网”或者“网速慢”，而是无线模块的驱动/固件层面失去了响应。因为它连iw dev wlan0 scan都执行不了，通常报command failed: Device or resource busy (-16)，这说明网卡的固件已经完全卡死，不再是用户态重连能救回来的状态。
1.2 排查之前，先想清楚三件容易被忽略的事
很多人一上来就重刷驱动、重装系统，其实浪费了大把时间。在动手之前，我建议先花五分钟把以下三个边界条件确认清楚，不然很容易被表面现象带偏。
供电是否稳定。Orin NX 整板功耗峰值能到 25W 左右，再加上 WiFi 高吞吐、USB 存储同时读写的时候，如果电源适配器功率不够或线材压降大，PCIe 外设可能会被瞬间断电或电压跌落触发复位。判断方法：上传大文件的同时观察dmesg里有没有voltage、power supply、resetting之类的关键字，以及 CPU 频率是否大幅抖动。我遇到的这次供电没毛病，用的是官方 45W DC 适配器。
路由器侧是否主动踢人。有些企业级或家用高端 AP 开了 band steering、802.11k/v/r 快速漫游、负载均衡功能，长时间高吞吐的连接可能被误判为“占用过高”而主动断开。判断方法：拿手机连同一个 AP，用测速工具持续上传几分钟，如果手机也掉，问题大概率在 AP 策略。如果只有 Orin NX 掉，再往后查。
网络栈“假掉线”与物理掉线的区别。有一种情况是 WiFi 还连着，但 systemd-resolved 的 DNS 出问题，导致ping baidu.com不行、但ping 网关 IP完全正常。这种情况不要瞎折腾驱动，先ping 网关判断链路是不是真的断了。我这台是网关都 ping 不通过，所以直接排除掉这个方向。
2. 根因分析：为什么“上传大文件”会带崩 WiFi
2.1 矛头直指网卡驱动与固件
先确认你手上网卡的真实身份，这一步非常关键。Orin NX 的 WiFi 大多是开发者自行采购的 M.2 Key E 模组，常见的有 Intel AX210/AX211、Realtek RTL8852BE、Realtek RTL8822CE 等。用下面两条命令就能看到：
lspci | grep -i network lspci -vnn | grep -i wireless我这次看到的是 Realtek RTL8852BE，对应内核驱动模块是rtw_8852be（内核 5.10 用的是 rtl 系列早期驱动，6.x 内核里会切换到 rtw89 驱动体系）。这个芯片在 Linux 下的口碑一直不太稳，尤其在高吞吐、长时间连续收发的时候，固件内部的状态机很容易崩。大文件上传意味着什么？意味着 TX 队列持续被打满、中断风暴不停、DMA 缓冲反复分配释放，任何一个环节出错，固件就可能进入“假死”——这时候驱动层面发任何命令给它，它都不回包了。
我在dmesg里抓到的典型报错包括：
rtw_8852be: firmware didn't respond rtw_8852be: failed to get tx descriptor这两个日志一旦出现，基本就可以判定是网卡固件侧的问题，而不是单纯的路由器把连接断了。顺带一提，Intel AX210 的 iwlwifi 驱动也会遇到类似场景，但固件崩溃率和恢复成功率都比 Realtek 好很多，后面长效方案里我会细说。
2.2 电源管理才是真正的帮凶
很多人遇到这个问题后第一反应是换驱动版本，结果换了还是一样，原因就在于忽略了一个潜伏因素：PCIe 电源管理。
无线网卡挂在 PCIe 总线上，默认会启用 ASPM（Active State Power Management）。简单理解就是：PCIe 链路在数据空闲的时候可以自动进入低功耗状态（L0s / L1），等有数据再快速醒过来。理论上这是好事，但 Realtek 网卡和 Jetson 定制内核的 ASPM 兼容性并不好。大文件上传时链路长时间处于高负载，一旦传输结束或出现短暂停顿，链路进入 L1 睡眠，然后因为某个寄存器握手失败，就再也醒不过来了。表现出来就是“网卡还在设备树里，但固件已经死了”。
另外还有一层：网卡驱动的运行时电源管理，也就是 D0/D3 状态切换。省电调度器在高负载结束后会把设备切到 D3hot，但驱动没准备好恢复时序，就会卡在切换过程中。关掉电源管理之后问题立刻消失，这也是为什么我后面会把power_save off作为第一优先级操作。
还有一个小帮凶是发热。Orin NX 整机被动散热时，M.2 槽周围温度不低，加上长时间高负载上传，Realtek 这枚芯片的发热量本身也不小，过热到一定程度会触发保护机制主动断射频。如果用热成像看过这类模组，会发现它们在连续跑吞吐时表面温度轻轻松松摸到 70-80 度。
2.3 用内核日志给故障定性
排查这种问题，内核日志是唯一靠谱的“黑匣子”。先用一条命令把现场留证：
dmesg -T | tail -n 200把日志分成三类来归类，我整理成一张速查表：
| 日志特征 | 可能原因 | 优先排查方向 |
|---|---|---|
firmware didn't respond、failed to get tx descriptor | 固件挂死 | 驱动版本、网卡兼容性 |
AER: Corrected error received、Unsupported Request | PCIe 链路异常 | ASPM、硬件接触、供电 |
link is not ready、no carrier | 驱动已加载但射频链路断开 | 天线、发射功率、路由器策略 |
| 重启后日志里某段时间网卡完全“沉默” | 固件最早就在那个时间点死亡 | 对照上传开始时间 |
一个比较实用的技巧：如果上传开始后的某个时间点，网卡相关日志完全消失，之后一切重连尝试都无效，那说明固件死亡的时刻基本就是日志沉默的时刻，后续的重试只是徒劳。这时直接进入下面的应急恢复流程。
3. 应急恢复：三步把 WiFi 救回来
3.1 第一步：确认状态，别急着整机重启
很多人的第一反应是reboot，这当然能恢复，但代价太大了。边缘设备往往跑着推理任务，整机重启意味着业务中断、推理进程死亡、模型重新加载要花时间。应急恢复的目标是用最小代价让 WiFi 接口复活。
先按顺序确认三件事：
ping -c 3 网关IP ip link show wlan0 nmcli device status如果ping不通，但wlan0还显示为 UP，说明可能是 IP 层问题，先重启 NetworkManager 试试：
sudo systemctl restart NetworkManager如果接口显示 UNKNOWN 或 DOWN，执行iw dev wlan0 link确认一下，大概率会报Device or resource busy。到这里就说明驱动已经不响应了，进入下一步。
3.2 第二步：卸载重载驱动，必要时重扫 PCIe 总线
先卸载网卡驱动模块。以 RTL8852BE 为例：
sudo lsmod | grep rtw sudo modprobe -r rtw_8852be但这里有个经典坑：如果驱动已经卡死，modprobe -r会挂住，因为它要等设备完成一次正常关闭流程。遇到这种情况，别干等，先停掉 NetworkManager 减少干扰：
sudo systemctl stop NetworkManager sudo modprobe -r rtw_8852be如果这样还是卡住，就直接走 PCIe 槽位级重置。简单说，就是把这个设备从 PCIe 总线上拔掉，再重新扫描让它重新枚举。先找到网卡的 PCI 地址：
lspci | grep Network假设输出是01:00.0，那么执行：
sudo sh -c 'echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove' sudo sh -c 'echo 1 > /sys/bus/pci/rescan'这个操作相当于给网卡做了一次“冷启动”，比modprobe重置更彻底。操作完以后看dmesg尾部，应该能看到设备重新枚举的日志，再启动 NetworkManager 就能正常连接。
我实际测试下来，这个办法对 Realtek 网卡的有效率在八成以上。要是连 PCIe rescan 都拉不回来，那基本就是硬件过热损坏或者驱动彻底刷坏了，再考虑重启。
3.3 第三步：关掉电源管理，一次顶住高负载
临时恢复连接之后，别急着继续传文件，先做一个关键操作：把无线网卡和 PCIe 链路的电源管理全部关掉。这是避免同样问题在几分钟内再次出现的核心手段。
# 关闭 802.11 省电模式（iw 没有就先安装） sudo apt install iw sudo iw dev wlan0 set power_save off # 关闭 PCIe 运行时电源管理 echo on | sudo tee /sys/bus/pci/devices/0000:01:00.0/power/control这两条命令的效果非常明显：关掉之后，我再跑同样的 rclone 上传，速度拉到 80MB/s 持续十几分钟，没有再出现一次掉线。原因就是前面说的，ASPM 低功耗切换和 802.11 power save 是触发固件挂死的最大诱因，禁掉之后，网卡始终处于满电活跃状态，虽然会多耗大约 0.5-1W 电，但对稳定性来说完全值得。
注意：这些设置在重启后会失效，所以如果你想彻底解决，必须把它们固化成开机自启任务。这个我在下一节讲长效方案的时候会给出完整的 systemd 配置。
4. 长效根治：如何在 Orin NX 上稳定跑大文件传输
4.1 优先考虑换无线网卡或升级驱动
先说一个残酷的现实：Realtek 某些型号在 Linux 下的驱动质量，就是不如 Intel 的方案稳定。如果你手头的板子能换 M.2 无线网卡，我个人的经验是直接换 Intel AX210 或 AX211，JetPack 自带 iwlwifi 固件，装上后 NetworkManager 直接识别，不需要装第三方驱动，跑高吞吐的稳定性比 Realtek 高一个档次。
换卡的注意事项，我列一下容易踩的坑：
- 确认接口协议：M.2 Key E 是必须的，别买成 Key A 或 Key B 的模块。
- 天线接头类型：常见 IPEX MHF4，也有老款 MHF1，不匹配就得买转接线。
- 网卡长度：2230 尺寸最通用，部分模组是 1216，自己看槽位螺丝位置。
- 换卡后首次开机建议拔掉交流电源彻底放电，有些主板没有重启复位 PCIe 设备的能力。
如果你暂时不想动硬件，那就围绕软件层面修补。比如内核 5.10 自带的是 Realtek 老版驱动，可以考虑找板卡厂商提供的定制驱动包，或者升级到 JetPack 6.x（内核 6.6 左右）看自带的 rtw89 驱动版本是否更新。不过 Jetson 的定制内核不能随便升级主线内核，需要看 NVIDIA 官方 L4T 是否支持，别自己编译内核，容易把 BSP 里的设备树和驱动兼容性搞崩。
4.2 调整内核与系统电源策略，固化到开机自启
软件层面的终极方案，其实就两条：让网卡无时无刻不处于“高功耗”状态，同时禁止 PCIe 链路休眠。把上一节的临时命令做成 systemd 服务，是最稳妥的落地方式。
先改内核启动参数，把 ASPM 彻底禁掉。找到/boot/extlinux/extlinux.conf，在 APPEND 那一行追加：
pcie_aspm=off pcie_port_pm=off注意 Jetson 的启动配置路径和传统 Ubuntu 不一样，不在 GRUB 里，别找错地方。改完保存后，用sync确保落盘，再重启生效。
然后再写一个 systemd 服务文件，开机后立即关掉无线模块的省电：
[Unit] Description=Disable WiFi power save and ASPM After=network.target [Service] Type=oneshot ExecStart=/usr/sbin/iw dev wlan0 set power_save off ExecStart=/bin/sh -c 'echo on > /sys/bus/pci/devices/0000:01:00.0/power/control' ExecStart=/usr/sbin/ethtool -s wlan0 wol d RemainAfterExit=yes [Install] WantedBy=multi-user.target注意0000:01:00.0这个 PCI 地址要根据你实际网卡的地址来替换，别直接抄。创建/etc/systemd/system/wifi-stability.service后：
sudo systemctl daemon-reload sudo systemctl enable --now wifi-stability.service然后确认状态：
systemctl status wifi-stability.service iw dev wlan0 get power_save如果能读到Power save: off，说明生效了。这套配置我用了大半年，Orin NX 上 WiFi 再没出现过上传大文件后假死的情况。
4.3 给上传任务做限速与适配，从源头降压
即使驱动和电源管理都处理好了，也建议在业务侧做一点妥协。大文件上传不一定要跑满速，尤其是对稳定性要求高的场景，限速反而是最划算的“保险”。
我常用的两个工具：
# rclone 限速到 30MB/s rclone copy /data/model.zip remote:/backup --progress --bwlimit 30M # rsync 限速到 5000KB/s rsync -avz --bwlimit=5000 /data/model.zip user@nas:/backup/注意 rclone 的--bwlimit默认单位是 bytes/s，30M表示 30MB/s，不是 30Mbps。如果你只想让上传占用的带宽控制在不干扰其他设备的水准，建议先测一下路由器实际宽带，再按比例限。
另外一个小技巧：把 MTU 从 1500 降到 1400。这个操作对 WiFi 这类的链路特别有用，因为无线链路的帧开销和有线不同，MTU 太大在高丢包环境下会触发大量重传，重传风暴反而更容易把弱鸡网卡固件冲垮。临时执行：
sudo ip link set wlan0 mtu 1400如果做了这一步发现连接更稳了，说明你的链路确实存在丢包和重传压力，可以考虑固化成 NetworkManager 连接配置里的 mtu 字段。上传任务本身的改造也有讲究：长任务尽量放在 tmux 或 screen 里跑，搭配断点续传参数，就算 WiFi 抖动一下也不至于从头开始。
5. 常见问题速查与踩坑实录
5.1 最值得记下的一张排查速查表
我把这段时间遇到的所有相似问题汇总成了一张表，以后遇到可以直接照表操作：
| 现象 | 常见原因 | 优先级最高的处理方法 |
|---|---|---|
| 上传大文件时 WiFi 彻底假死，nmcli 重连失败 | 网卡固件挂死 | modprobe -r / PCIe rescan |
| 持续传半小时后网速骤降，但系统还能 ssh | 路由器限速或信号干扰 | 确认 AP 策略、切换 5GHz 信道 |
| 只有网盘域名 ping 不通，网关和公网 IP 都通 | DNS 与本地网络栈问题 | 检查 systemd-resolved，换公共 DNS |
| 插上 USB 3.0 移动硬盘上传时 WiFi 掉线 | 2.4GHz 射频干扰 | 改用 5GHz 频段，USB 硬盘远离天线 |
| 上传到一半系统直接重启 | 供电不足或过热保护 | 确认电源适配器功率，检查散热 |
5.2 三条“奇怪但真实”的野外经验
第一，USB 3.0 对 2.4GHz 频段的射频干扰是真实存在的，而且显著。插着 USB 3.0 移动硬盘做上传源、WiFi 用的是 2.4GHz 频段，WiFi 掉线的概率会大幅上升。后来我把 WiFi 切到 5GHz，同样条件下一次都没掉过。如果你的环境只能用 2.4GHz，建议把 USB 设备用延长线拉远至少 30cm，或者换屏蔽线缆。
第二，板卡装在金属机箱里时，天线位置极其关键。有些 NX 套件整个放在 DIN 导轨的金属导轨架上，天线紧贴着金属外壳，信号衰减非常严重。这种环境下的表现就是：信号强度显示满格，但长时间高吞吐会“假断”，因为一有干扰，重传率高到驱动扛不住。处理方法：尽量把天线甩到机箱外面，磁吸天线也不要贴在金属平面上。
第三，M.2 无线网卡和 SSD 共用一个散热区域的话，要注意热量的互相传导。上传文件时如果本地同时在写缓存文件，SSD 发热会把热量导给旁边无线网卡，网卡过热后主动掉射频，表现也是“几分钟内必掉线”。看 dmesg 虽然能看到固件无响应，但真正的根因是温度。这种情况优先改善 M.2 区域的通风，别盲目换驱动。
5.3 用自动看门狗代替人工值守
如果你设备部署在无人值守的现场，又不能立刻改硬件，写一个简单的看门狗脚本是最后的保底手段。原理很简单：定时 ping 网关，连续失败达到阈值，就自动重置网卡驱动，而不是整机重启。
#!/bin/bash GATEWAY="192.168.1.1" PING_FAIL=0 DEV_PCI="0000:01:00.0" while true; do if ping -c 1 -W 2 "$GATEWAY" > /dev/null 2>&1; then PING_FAIL=0 else PING_FAIL=$((PING_FAIL + 1)) if [ "$PING_FAIL" -ge 5 ]; then logger "WiFi watchdog: restarting wireless driver" timeout 15 sudo modprobe -r rtw_8852be 2>/dev/null sleep 2 sudo modprobe rtw_8852be 2>/dev/null if ! ip link show wlan0 2>/dev/null | grep -q "state UP"; then logger "WiFi watchdog: PCIe rescan fallback" echo 1 | sudo tee /sys/bus/pci/devices/$DEV_PCI/remove echo 1 | sudo tee /sys/bus/pci/rescan fi sleep 10 PING_FAIL=0 fi fi sleep 10 done这个脚本摆脱了传统modprobe -r可能卡死的问题，timeout 15会强制结束卡死的卸载进程，然后通过 PCIe rescan 做二次兜底。把它注册成 systemd 服务，配置Restart=always即可。我用这个方案顶了一周，直到新网卡到货，期间没有再出现过需要人工跑机房的情况。
我个人最后的结论是：Jetson 这类边缘板子，稳定性永远比峰值性能重要。如果你也要长期用它传大文件，有条件就直接换 Intel 无线网卡，配上关闭电源管理的系统服务，再给上传任务加一个限速参数，三管齐下基本能根治。软件能打的补丁都打了之后，剩下的问题大概率就只是硬件选型问题了。
