[RESPONDED] Wifi unable to reconnect after hibernation AMD

I am unable to reconnect to my wifi after hibernating, even if I cycle the card completely (e.g. turn it off and on using nmcli). The logs seem to be stuck in auth timeout cycle. Rebooting works and everything starts up ok so it’s really odd.

IWD seems to have the same issue, works first time / over reboots but fails after hibernation. Is anything known about this issue?

Logs are basically a repeat of

<info>  [1707594978.2327] device (wlp1s0): Activation: (wifi) connection 'WIFI_SSID 1' has security, and secrets exist.  No new secrets needed.
<info>  [1707594978.2327] Config: added 'ssid' value 'WIFI_SSID'
<info>  [1707594978.2327] Config: added 'scan_ssid' value '1'
<info>  [1707594978.2328] Config: added 'bgscan' value 'simple:30:-70:86400'
<info>  [1707594978.2328] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK SAE FT-SAE'
<info>  [1707594978.2328] Config: added 'auth_alg' value 'OPEN'
<info>  [1707594978.2328] Config: added 'psk' value '<hidden>'
<info>  [1707594978.7636] device (wlp1s0): supplicant interface state: disconnected -> authenticating
<info>  [1707594978.7637] device (p2p-dev-wlp1s0): supplicant management interface state: disconnected -> authenticating
<info>  [1707594982.3160] device (wlp1s0): supplicant interface state: authenticating -> disconnected
<info>  [1707594982.3161] device (p2p-dev-wlp1s0): supplicant management interface state: authenticating -> disconnected
<info>  [1707594982.4250] device (wlp1s0): supplicant interface state: disconnected -> scanning
<info>  [1707594982.4251] device (p2p-dev-wlp1s0): supplicant management interface state: disconnected -> scanning

NOTE: firmware version is reported as mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20231120183441

Do we have a distro release and kernel version? Looks like you’re on the latest firmware for the Mediatek card, but I’d like to understand what distro you’re on.

Arch Linux running 6.7.4-arch1-1 #1 SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Nothing custom about it (e.g. stock Arch kernel). I played around with IWD a bit more and I can get network working with iwd after hibernation, using iwd as the NetworkManager backend, BUT only if I manually “disanble and reenable” wifi and connect again.

Understood. I am not on Arch and have not tested it against it (as it’s purely community support), however is this happening with the new firmware? Looks like you have a 20231120183441 build which is newer and correct.

In a pinch, while kludgy, you could roll a systemd service to look for a resume state, rfkill disable and enable your wifi. I’ve done this in the past when connecting or disconnecting from AC power (this was sometime ago).

I found out that using iwd things work out if I shut off the wifi and re-enable. It’s “good enogh” for now, I hope this gets fixed. Oddly enough the errors in iwd log don’t seem to show anything “new”.

I’ve been having this intermittently myself, using NetworkManager on Arch. Currently using the same workaround of re-enabling wifi after sleep. It’s quite an irony, I updated to the newest linux-firmware-git to get a newer APU firmware to solve the random freezes and it broke the wifi card instead…

I have the same thing. It’s very annoying. I’m on Arch Linux as well with NetworkManager.
rfblock block 1 && rfblock unblock 1 doesn’t work.

echo 1 |sudo tee /sys/bus/pci/devices/0000:01:00.0/remove && sudo tee /sys/bus/pci/rescan

fixes it.

Note that I’m not using the iwd backend, I’m using the normal wpa_supplicant backend of NetworkManager.

I am seeing exactly the same issue.

My system is 13 AMD Ryzen 7840U, Bios 03.03, Debian 12, Kernel 6.7.4, firmware 20230625 (from .deb) + newest updates 20240115 of amdgpu & mediatek firmware.

After coming back from hibernation, wifi is not reconnecting. After rebooting the system, the issue seems gone. It does not happen when waking up from suspend.

In my case, PCI remove & rescan alone does not help. To fix that, I have to do modprobe -r mt7921e && modprobe mt7921e before the rescan.

I had the same problem and ditched the mediatek for a Amazon.co.uk

Most of my suspend/resume problems have gone away (except for one I’m still trying to figure out)

Some additional info: it seems that iwd is not immune to getting stuck in a “unrecoverable” state either. I just had it unable to reconnect after hibernation, tho unlike with wpa_supplicant it seems to only happen 1/4 or so hibernations.
Also dmesg shows errors until i reload the module, here’s the log:

[  132.240588] mt7921e 0000:01:00.0: Message 00000010 (seq 9) timeout
[  132.240606] mt7921e 0000:01:00.0: Failed to get patch semaphore
[  135.440958] mt7921e 0000:01:00.0: Message 000046ed (seq 10) timeout
[  135.441153] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xffdcee00 flags=0x0000]
[  136.612492] ucsi_acpi USBC000:00: unknown error 0
[  136.612511] ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5)
[  138.640962] mt7921e 0000:01:00.0: Message 00000010 (seq 11) timeout
[  138.640981] mt7921e 0000:01:00.0: Failed to get patch semaphore
[  138.641202] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xfef07580 flags=0x0000]
[  141.840513] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[  141.840603] mt7921e 0000:01:00.0: Message 00000010 (seq 12) timeout
[  141.840618] mt7921e 0000:01:00.0: Failed to get patch semaphore
[  145.041089] mt7921e 0000:01:00.0: Message 00000010 (seq 13) timeout
[  145.041107] mt7921e 0000:01:00.0: Failed to get patch semaphore
[  148.240599] mt7921e 0000:01:00.0: Message 00000010 (seq 14) timeout
[  148.240618] mt7921e 0000:01:00.0: Failed to get patch semaphore
[  148.240781] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xea365800 flags=0x0000]
[  148.240805] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xea365800 flags=0x0000]
[  148.240822] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xea365800 flags=0x0000]
[  151.440715] mt7921e 0000:01:00.0: Message 00000010 (seq 15) timeout
[  151.440734] mt7921e 0000:01:00.0: Failed to get patch semaphore
[  154.640960] mt7921e 0000:01:00.0: Message 00000010 (seq 1) timeout
[  154.640980] mt7921e 0000:01:00.0: Failed to get patch semaphore
[  154.641161] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xda50f800 flags=0x0000]
[  154.641185] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xda50f800 flags=0x0000]
[  154.641202] mt7921e 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0xda50f800 flags=0x0000]
[  157.840980] mt7921e 0000:01:00.0: Message 00000010 (seq 2) timeout
[  157.840998] mt7921e 0000:01:00.0: Failed to get patch semaphore
[  161.040533] mt7921e 0000:01:00.0: Message 00000010 (seq 3) timeout
[  161.040550] mt7921e 0000:01:00.0: Failed to get patch semaphore
[  161.040578] mt7921e 0000:01:00.0: chip reset failed
[  179.385270] mt7921e 0000:01:00.0: ASIC revision: 79220010
[  179.465610] mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20231120183400a
perfmed a "RFBUMP" here by stopping iwd and networkmanage + doing a modprobe remove and re-add on `mt7921e`
[  179.833448] mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20231120183441
[  184.526895] wlan2: authenticate with <redacted> (local address=<redacted>)
[  185.003676] wlan2: send auth to <redacted> (try 1/3)
[  185.006749] wlan2: authenticated
[  185.007144] wlan2: associate with <redacted> (try 1/3)
[  185.020672] wlan2: RX AssocResp from <redacted> (capab=0x11 status=0 aid=2)
[  185.047869] wlan2: associated

Same issue here, with Archlinux 6.7.4-arch1-1.

My dance after hibernation is: Enable flight mode, wait 1-2 secs, disable flight mode. If the Wifi won’t connect then, I’ll restart iwd and NetworkManager (NM is configured to use iwd as backend). Works 9 out of 10 times, my guess.

Sometimes, NetworkManager fails to connect but iwd still can. Connecting directly via iwctl often fixes this. Some helpful commands in iwctl are:

device wlan0 set-property Powered off
device wlan0 set-property Powered on
station wlan0 scan on
station wlan0 get-networks
station wlan0 connect <insertyouressidhere>

When all this fails, instead of a reboot, it’s still possible to reload the kernel module (as root):

modprobe -r mt7921e
modprobe mt7921e

Then restart iwd and NM again. The device name will change to the next higher number, e.g. from wlan0 to wlan1. This seems to confuse autoconnect but it’s possible to get a connection with iwctl.

Oh, and seems like this will be fixed with 6.8, see here: [Framework 13 AMD] Issues with wireless after resume - #5 by mxsc