记一次 Intel AX200 在 Linux 下 Wi-Fi 消失的排查：Reboot is not a power cycle

Kaku Lv4
  2026-08-11 20:00 2026-08-11 20:00 创建   2026-08-11 18:14:53 2026-08-11 18:14:53 更新   

前言

机器是一台 GEM12 小主机，内部用的 Intel AX200 无线网卡。

现象很简单也很气人：lspci 能认出这张卡，但系统里就是没有 Wi-Fi 接口。iw dev 没输出，ip link 里找不到 wlan0 或者 wlp*，rfkill 里只有 Bluetooth。

换发行版也没用。Fedora Live CD、Ubuntu 22.04、新版 Ubuntu，结果完全一样。

最后是怎么解决的？没有重装驱动，没有换 firmware，没有换内核，也没有改 NetworkManager。只是把机器彻底断了电，冷启动一次，就好了。

这篇把排查过程记下来。重点不在 AX200 本身，而是这次排障揭示的一个很多人容易忽略的事实：

删除操作系统，不会重置硬件。reboot 不等于 power cycle。

故障现象

先列出全部现象：

  • lspci 能正常识别 AX200；
  • 系统中没有 Wi-Fi 接口；
  • iw dev 无输出；
  • ip link 中不存在 wlan0 / wlp*；
  • rfkill 只显示 Bluetooth，没有 Wireless LAN；
  • Bluetooth 可以正常工作；
  • 换多个 Linux 发行版结果完全一致。

也就是说，基本可以排除这些常见嫌疑：

  • NetworkManager 配置问题；
  • 单一发行版的问题；
  • 内核版本太旧；
  • 普通的 Wi-Fi 配置错误。

第一条线索：lspci 认了卡，驱动没绑上

先看硬件识别情况：

1
sudo lspci -nnk | grep -A4 -Ei 'network|wireless'

实际输出：

1
2
3
4
5
6
7
04:00.0 Network controller [0280]:
Intel Corporation Wi-Fi 6 AX200 [8086:2723] (rev 1a)

Subsystem:
Intel Corporation Wi-Fi 6 AX200NGW [8086:0084]

Kernel modules: iwlwifi

注意最后两行的区别。

Kernel modules: iwlwifi 表示内核知道「这个 PCI ID 应该由 iwlwifi 驱动接管」。

但下面没有 Kernel driver in use: iwlwifi。

这说明 Linux 认识这张卡、也知道该用哪个驱动，但驱动在 probe 阶段没有成功完成，没能绑定设备。问题不在「认不认识」，而在「初始化能不能做完」。

第二条线索：模块加载了，绑定数却是 0

再看模块状态：

1
lsmod | grep -E 'iwlwifi|iwlmvm'

实际输出：

1
2
iwlwifi    655360    0
cfg80211  1536000    1 iwlwifi

iwlwifi 后面的 0 是「被引用计数」。模块已经加载，但没有任何设备成功绑定到它。

cfg80211 显示 1 iwlwifi 只是模块依赖关系（iwlwifi 依赖 cfg80211），不代表有无线接口创建成功。

两条线索指向同一个方向：probe 失败。但真正让问题坐实的，是 dmesg。

决定性线索：dmesg 里的 -110

1
sudo dmesg | grep -i iwlwifi

关键几行（实际日志）：

1
2
3
4
iwlwifi 0000:04:00.0: enabling device (0000 -> 0002)
iwlwifi 0000:04:00.0: CSR_RESET = 0x10
...
iwlwifi 0000:04:00.0: probe with driver iwlwifi failed with error -110

-110 在 Linux x86 架构上就是 -ETIMEDOUT，操作超时。

也就是说，iwlwifi 在初始化 AX200 的硬件环节等待设备响应，等不到，超时退出。整个流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
PCIe 枚举
   ↓
识别 AX200 (8086:2723)
   ↓
加载 iwlwifi
   ↓
enable PCI device
   ↓
reset / wake / 硬件初始化
   ↓
设备没有正常响应        ← 卡在这里
   ↓
ETIMEDOUT (-110)
   ↓
probe 失败，设备没有绑定

问题甚至发生在正常 firmware 加载之前。所以日志里根本看不到 loaded firmware version 之类的正常启动信息——没有走到那一步。

到这里可以下一个初步结论：

问题已经不在 Wi-Fi 配置、NetworkManager 或者发行版层面，而是在 PCIe / 驱动 probe / 硬件初始化这一层。

关键旁证：蓝牙是正常的

日志里蓝牙一路正常：

1
2
3
Bluetooth: hci0: Found device firmware: intel/ibt-20-1-3.sfi
Bluetooth: hci0: Firmware loaded
Bluetooth: hci0: Firmware revision 0.3 build 83 week 7 2026

AX200 这个 M.2 模块里，Wi-Fi 和蓝牙并不是同一个逻辑设备：

1
2
3
4
5
6
                  Intel AX200
        ┌──────────────────────┐
PCIe ───┤ Wi-Fi MAC/PHY        │   ← 初始化失败
        │                      │
USB ────┤ Bluetooth            │   ← 完全正常
        └──────────────────────┘

Wi-Fi 走 PCIe，蓝牙走 USB（挂在模块内部通往主板的 USB 通道上）。所以「同一张卡，蓝牙正常、Wi-Fi 卡死」完全可能出现，并不矛盾。

这反而让问题更聚焦：USB 那一半好好的，PCIe 那一半初始化超时——嫌疑集中在 PCIe 链路和 Wi-Fi 部分的电源 / 复位状态上。

另一个旁证：BIOS / ACPI 里有 WLAN 相关错误

启动日志里还有这样几行：

1
2
3
ACPI: SSDT ... AMD WLAN ...
ACPI BIOS Error (bug): Could not resolve symbol
[\_SB.PCI0.GPP6.WLAN], AE_NOT_FOUND

BIOS 提供了一个和 WLAN 有关的 SSDT，但里面引用的 \_SB.PCI0.GPP6.WLAN 对象在系统里不存在。

要说明白：这个错误不能单独证明它就是 AX200 故障的原因，只能算旁证。但它把怀疑范围拓宽了——AMD 平台、WLAN 的 PCIe 槽位、BIOS 提供的 ACPI 表、iwlwifi 初始化超时，这些凑在一起，一度让人怀疑是不是 BIOS/ACPI、PCIe 电源管理、WLAN reset（PERST#）、ASPM 之类的问题。

结果谁也没想到，答案比这简单得多。

最终解决办法：彻底断电

所有软件层面的手段都没有用，最后解决的办法是：

对整台机器做一次真正的完全断电 / 冷启动。

具体步骤：

1
2
3
4
5
6
7
8
9
Linux 正常关机
   ↓
拔掉主机 DC 电源适配器
   ↓
断开可能反向供电的设备（比如 USB-C）
   ↓
长按电源键 30 秒，把残余电量放干净
   ↓
重新插上电源，开机

GEM12 这类小主机是 DC 供电，没有 ATX 电源上的物理开关，所以「断电」必须靠拔掉 DC 适配器。如果接着 USB-C 之类的口子，有些设备会反向给主板供电，也要一起断开。

「长按电源键 30 秒」这一步不是我想出来的。后来翻到 Ubuntu 社区一个帖子，有人遇到几乎一模一样的情况：Beelink SER5 Pro（也是 AMD 小主机）上的 AX200，同样能被 lspci 认出来、同样报 error -110、同样换内核、关 ASPM、重置 BIOS 全都没用。回复里给的办法就是拔电后长按电源键 30 秒再开机，发帖人回帖说 “That worked perfectly”。

之后 AX200 恢复正常，Wi-Fi 接口正常出现。

为什么删掉了 Windows，问题还在

这是整个事件最值得记录的部分。

这台机器之前装过 Windows，后来格式化硬盘、装了 Linux。Windows 的文件早就不存在了，为什么网卡还是「带着毛病」？

因为磁盘上的操作系统状态，和硬件内部的运行状态，是两回事。

PCIe 设备内部有自己的状态机、寄存器、firmware、SRAM，还有 power-management 状态和 reset 状态。只要设备还带着电，这些状态就可能一直保留着。

于是可能发生过这样的事：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Windows 最后一次操作 AX200
   ↓
网卡进入异常 power / reset 状态
   ↓
硬盘被格式化，Windows 被删除
   ↓
Linux 安装完成
   ↓
reboot
   ↓
AX200 一直没有真正断电
   ↓
异常状态原样保留
   ↓
iwlwifi probe 超时 (-110)

更准确的说法不是「Windows 的文件残留影响 Linux」，而是：

上一次操作系统（或上一次驱动）最后控制硬件时留下的设备状态，一直没有被真正的掉电复位清掉。

Windows 已经不存在了，留下来的是硬件自己的状态。

为什么 reboot 不够

「CPU / 系统重启」和「PCIe 设备完全掉电复位」不是一回事。

PCIe 设备可以经历不同等级的 reset，从轻到重大致是：

1
2
3
4
5
6
7
8
9
驱动卸载 / 重新加载
   ↓
Function Level Reset (FLR)
   ↓
PCIe Bus Reset
   ↓
PERST# 硬件复位
   ↓
Power Cycle（真正掉电）

这些 reset 并不等价。有的设备不支持 FLR；BIOS 在 warm reboot 时不会真正切断设备电源；很多主板重启时也不会完整拉低 WLAN 的 reset 脚；M.2 的 3.3V 供电在重启过程中始终存在。

所以 reboot 很多时候只是：

1
2
3
4
5
CPU 复位
   ↓
重新跑一遍 BIOS / UEFI 的部分流程
   ↓
重新枚举 PCIe

AX200 内部那个异常状态，却原样保留着。

这也解释了为什么换 Fedora、换 Ubuntu、换内核全部失败——因为每次面对的，都是同一个没有真正 reset 过的硬件。

为什么普通关机也不够

现代 PC 在 ACPI S5「关机」状态下，主板并不一定是完全无电的。

电源输出的 rail 大致可以分成两路：

1
2
3
4
5
6
电源
 ├── Main Rails（+12V / +5V / +3.3V 主供电）
 │       └── 关机后关闭
 │
 └── Standby / Auxiliary Power（+5VSB 待机供电）
         └── 关机后仍然存在

待机电源要养活一堆东西：Wake-on-LAN、USB 唤醒、EC、蓝牙、RTC、USB-C / PD 控制器、PCIe wake、无线模块的辅助供电等等。

所以想真正清空硬件状态，很多时候必须：

1
2
3
4
5
6
7
8
9
关机
   ↓
拔掉 AC / DC
   ↓
必要时断开 USB-C 等外部供电
   ↓
等电容放电
   ↓
重新上电

这才是真正意义上的 power cycle。

Windows Fast Startup：值得警惕，但这次不一定就是它

Windows 的 Fast Startup 不是一个普通的关机。开启后，Windows 在「关机」时会保存一部分内核 session，对设备执行电源管理，把设备切进低功耗状态。

这个坑有多经典？iwlwifi 的官方文档里专门有一节讲双系统 + Windows Fast Boot 导致的 Wi-Fi 初始化问题，给出的建议就是直接关掉 Fast Startup。Ubuntu 社区那个同样卡在 -110 的帖子里，回复者也直接点了一句：「这可能是 Windows 混合关机（hybrid shutdown）留下的状态」——和这里是同一个怀疑。

但要注意，这次的情况有点特殊：Windows 已经被删掉了，硬盘上只剩 Linux。所以严格来说，没法确认这次是不是 Fast Startup 留下的状态。它只是同类故障里一个高频、且被官方点名过的嫌疑。

不管是不是它，逻辑是一样的：前一个系统最后一次控制硬件时，可能留下了一个没被复位掉的设备电源状态。

这类问题该怎么排

如果你也遇到类似现象：

1
2
3
lspci 能识别设备
Kernel modules 指向的驱动也对
但没有 Kernel driver in use

先别急着折腾这些：

  • 不要先怀疑 NetworkManager / Wi-Fi 配置；
  • 不要先怀疑 firmware 包；
  • 不要先怀疑发行版；
  • 不要一上来就重装系统。

第一步先看日志：

1
sudo dmesg | grep -i <driver>

如果看到 probe failed、error -110、timeout、reset failed、device not ready 这类关键字，说明问题已经在 PCIe / 驱动 probe / 硬件初始化这一层。此时换桌面环境、换网络管理器、甚至换发行版，基本都没有意义。

特别是当「多个发行版 + 多个内核 + 同一块硬件 + 完全相同的 probe error」同时出现时，优先按这个顺序试：

  1. 完全断电（免费，先试这个）；
  2. BIOS 恢复默认 / 重置；
  3. PCIe power state、ASPM 相关设置；
  4. ACPI 相关设置；
  5. 检查硬件本身，换卡做 A/B 测试。

总结

这次故障可以浓缩成一句话：

操作系统已经被删除，不代表操作系统最后留下的硬件运行状态也被删除。只有真正让设备掉电，才能保证设备内部的状态机、寄存器和 firmware 状态被彻底复位。

更工程化一点：

Reboot is not a power cycle. Reinstalling the OS is not a hardware reset.

这个结论不只在 AX200 上成立。GPU、NVMe SSD、HBA、万兆网卡、Thunderbolt / USB4 控制器、BMC，这些复杂设备都可能出现同类问题：reboot 无效、驱动重载无效、重装系统无效，彻底断电后恢复正常。

下次再遇到「硬件看着都在，就是起不来」，可以先想想：它上一次真正掉电，是什么时候？

参考资料

  • 标题: 记一次 Intel AX200 在 Linux 下 Wi-Fi 消失的排查：Reboot is not a power cycle
  • 作者: Kaku
  • 创建于 : 2026-08-11 20:00:00
  • 更新于 : 2026-08-11 18:14:53
  • 链接: https://www.kakunet.top/2026/08/11/记一次Intel-AX200在Linux下Wi-Fi消失的排查/
  • 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
评论
目录
记一次 Intel AX200 在 Linux 下 Wi-Fi 消失的排查：Reboot is not a power cycle
  1. 前言
  2. 故障现象
  3. 第一条线索：lspci 认了卡，驱动没绑上
  4. 第二条线索：模块加载了，绑定数却是 0
  5. 决定性线索：dmesg 里的 -110
  6. 关键旁证：蓝牙是正常的
  7. 另一个旁证：BIOS / ACPI 里有 WLAN 相关错误
  8. 最终解决办法：彻底断电
  9. 为什么删掉了 Windows，问题还在
  10. 为什么 reboot 不够
  11. 为什么普通关机也不够
  12. Windows Fast Startup：值得警惕，但这次不一定就是它
  13. 这类问题该怎么排
  14. 总结
  15. 参考资料