ASUS X870‑F Gaming WiFi: PCIe/ACPI regression in kernel 7.0.0‑28‑generic causing CNVi Wi‑Fi device non‑enumeration and ACPI S5 shutdown failure(Wifi issue has been resolved)

[GhostWolf188]

PCIe Enumeration Regression (Wi‑Fi Device Missing)

Observed Behavior

Under kernel 7.0.0‑28‑generic:

• The onboard CNVi/M.2 Wi‑Fi module does not appear in lspci at all.
• No PCIe function corresponding to Intel/MediaTek CNVi/M.2 Wi‑Fi is present.
• No driver attempts to bind:
  • iwlwifi
  • mt76
  • mt7921e
• No firmware requests appear in dmesg.

This indicates the Wi‑Fi PCIe function never initializes.

---

Expected Behavior

Under kernels 6.6 LTS and 6.8:

• Wi‑Fi module enumerates normally on PCIe.
• Correct driver loads automatically.
• Wireless interfaces appear in NetworkManager.

---

Evidence

Relevant PCIe devices from lspci -vv:

08:00.0 Ethernet controller: Intel I226‑V
1-11:15 Bluetooth USB device (Foxconn/Hon Hai)

Missing:

No CNVi/M.2 Wi‑Fi device anywhere in domain 0000:

• No Intel AX2xx
• No MediaTek MT7921/MT7925
• No Qualcomm CNVi

This confirms the Wi‑Fi PCIe function:

• never leaves D3cold, or
• is never powered by ACPI _PR3.

---

Likely Technical Causes

• ACPI _PR3 power resource not applied to the Wi‑Fi device
• PCIe root port fails D3cold → D0 transition
• Regression in AMD ACPI/PCIe initialization introduced in kernel 7.0
• ASUS ACPI tables require vendor‑specific handling not applied in 7.0
• AGESA ACPI method changes not accounted for in kernel 7.0

These are consistent with known regressions on AMD AM5 + ASUS boards when ACPI tables and PCIe initialization sequences change between kernel versions.

---

ACPI S5 Shutdown Regression

Observed Behavior

Under kernel 7.0.0‑28‑generic:

• systemd reaches poweroff.target and reports a clean shutdown.
• systemd-poweroff.service completes successfully.
• The system remains physically powered on:
  • Fans keep spinning.
  • LEDs stay lit.
• A long press of the physical power button is required to actually power off the machine.

Under older kernels (6.6 LTS / 6.8), the system powers off normally.

---

Key Log Evidence

From dmesg | grep -i acpi:

• ACPI reports support for S0 S3 S4 S5:
  • ACPI: PM: (supports S0 S3 S4 S5)
• ACPI tables (XSDT, DSDT, SSDTs) load successfully with no reported errors.
• ACPI is used for PCI and interrupt routing:
  • PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug

From journalctl -b -1 | grep -i "power":

• Shutdown path is executed:
  • systemd-logind[841]: The system will power off now!
  • systemd-logind[841]: System is powering down.
  • systemd[1]: Finished systemd-poweroff.service - System Power Off.
  • systemd[1]: Reached target poweroff.target - System Power Off.
• But hardware does not actually transition to S5 (power off).

From dmesg:

• x86/amd: Previous system reset reason [0x00200800]: ACPI power state transition occurred

This suggests ACPI attempted a power state transition, but the platform did not complete the S5 power-off sequence.

---

Technical Interpretation

Likely causes:

• Failure to correctly assert SLP_TYP / SLP_EN for the _S5 state.
• Regression in ACPI shutdown handling for AMD AM5 platforms in kernel 7.0.
• ASUS ACPI/firmware interaction changed and is no longer handled correctly by the 7.0 kernel.
• Possible dependency on the same ACPI/PCIe power resource logic that is also failing for the Wi‑Fi device.

The combination of:

• Clean userspace shutdown,
• ACPI reporting S5 support,
• Logged ACPI power state transition,
• But no actual hardware power-off,

indicates a kernel–firmware ACPI S5 regression, not a userspace or configuration issue.

---

Environment

Motherboard: ASUS ROG STRIX X870-F GAMING WIFI (Rev 1.xx)
BIOS Version: 1203 (03/04/2025)
CPU: AMD Ryzen 7 9850X3D (AM5)
Distro: Linux Mint 22.3 (Ubuntu 24.04 noble)
Kernel (broken): 7.0.0-28-generic
Kernel (working): 6.6.x LTS, 6.8.x

Wi‑Fi Not Detected on ASUS X870‑F (Linux Mint 22.3) — Resolution Summary

Summary

After updating to kernel 7.0.0-28-generic, the system’s onboard Wi‑Fi stopped appearing entirely in lspci. Bluetooth continued working, but the Wi‑Fi PCIe function was missing across multiple kernels (7.0.0‑28, 6.17.x, 6.14.x).
This indicated a firmware‑level ACPI/PCIe power sequencing failure, not a driver or kernel issue.

A full ACPI power‑cycle resolved the issue and restored Wi‑Fi enumeration.

Symptoms

• Wi‑Fi completely missing from lspci
• No Network controller device present
• Bluetooth still functional
• Multiple kernels tested (6.14, 6.17, 7.0) — Wi‑Fi missing on all
• BIOS reported Wi‑Fi as “Enabled”
• No ACPI device node for Wi‑Fi
• No driver attempts (iwlwifi, mt7921e, etc.)

This combination strongly suggests the Wi‑Fi PCIe function was stuck in D3cold (fully powered off).

Diagnosis

Because Bluetooth worked but Wi‑Fi did not, the onboard wireless chipset was partially powered:

• Bluetooth = USB interface → powered
• Wi‑Fi = PCIe interface → unpowered

Linux cannot detect or load drivers for hardware that firmware never powers or enumerates.

This pointed to a firmware/ACPI power resource failure, not a Linux regression.

Fix: Full ACPI Power‑Cycle

Performing a complete power discharge forced the motherboard to reapply ACPI _PR3 power resources and reinitialize the Wi‑Fi PCIe function.

Steps performed:

1. Shut down the system
2. Switched PSU off
3. Unplugged power cable
4. Waited 10 seconds
5. Pressed power button once to discharge capacitors
6. Reconnected power
7. Booted system normally

Result:

• Wi‑Fi PCIe device reappeared in lspci
• Wi‑Fi functionality restored
• No further changes required

Conclusion

The issue was caused by the motherboard firmware leaving the onboard Wi‑Fi PCIe function in a powered‑off state (D3cold) after a kernel update.
A full ACPI power‑cycle restored proper hardware initialization.

This is a known behavior on some ASUS AM5 boards (X670/X870 series) where ACPI power resources may fail to apply after firmware or kernel changes.

[GhostWolf188]

So TLDR

when the power sequence was stopped by the 7.0.0 update it left my wifi in a partialy powered state and did not shut down completely i had to physicaly power down and remove the power cable and force a true power off to get wifi back

power down on 7.0.0 remains an issue tho

[Fantu]

In recent kernels, it seems to me that they've added stricter rules that can cause problems in poorly developed firmware, as appears to be the your case.
It seems that the analysis you had an LLM do also identified the cause. I saw in conclusion:

This is a known behavior on some ASUS AM5 boards (X670/X870 series)...

Update the firmware, if you haven't already done so and if there are updates for that motherboard.

If the problem persists, check if it's already reported on Launchpad (Ubuntu Bugtracker). It's likely already reported, and you should see if updates are planned and if there are workarounds listed as kernel parameters to pass at boot.

[GhostWolf188]

Thank you Fantu,
this was step one i did but alas no joy i have checked if there was any similar but i haven't seen any yet so it may not be wide spread yet as of this post. I'm currently running on an older kernel version via advanced grub startup and that has provided a work around till the firmware adequately supports my hardware.

[Fantu]

Unfortunately, I see a lot of problems with poorly-built firmware or bugs, only some of which are resolved with firmware updates. The kernel contains many workarounds to workaround firmware bugs, but they're not always enough, and in some cases they can cause problems, so they're removed.
Unfortunately, having open and well-supported firmware (with far fewer of these problems) remains a pipe dream.
I don't have time to research thoroughly, and as is often the case recently, Launchpad is experiencing slowness and failed loading (I assume due to an overload of bot requests, especially LLM).
Using a older kernel remain the easy and faster workaround (except you need newer kernel for something important).
Experimenting with kernel parameters at boot time is best done only if you have a minimum amount of experience, and not just blindly following an LLM's instructions. You should at least be able to remove the changes made from the grub menu if the system no longer boots properly.