Jul 24 reproduction and live-state capture
I reproduced the failure again on Jul 24 while Ethernet was also
connected, which masked the loss of Wi-Fi connectivity.
During the failure, the kernel reported:
iw dev wlx289401d29b8e link
Not connected.
However, NetworkManager continued to report the Wi-Fi device as
connected and retained the previous IP address and gateway.
A direct wireless scan still completed successfully and returned nearby
access points, so the USB adapter, PHY, and scanning path remained
functional.
A privileged control request to wpa_supplicant timed out:
sudo wpa_cli -i wlx289401d29b8e status
'STATUS' command timed out.
The live kernel stack for the wpa_supplicant main thread was:
sock_alloc_send_pskb
packet_snd
packet_sendmsg
__sys_sendto
/proc/<pid>/wchan also showed:
sock_alloc_send_pskb
The blocked system call was a sendto() on file descriptor 12. I mapped
fd 12 to socket inode 23010. /proc/net/packet identified that socket as
an AF_PACKET datagram socket using protocol 0x888e:
Proto: 888e
Inode: 23010
Rmem: 69120
ss -m -A packet -ap showed:
users:(("wpa_supplicant",pid=1557,fd=12))
Recv-Q: 69120
skmem:(r69120,rb212992,t213120,tb212992,...)
Therefore, at the time of the hang, the EAPOL AF_PACKET socket’s
transmit-memory accounting was at or slightly above its configured send-
buffer limit while wpa_supplicant was blocked in sock_alloc_send_pskb()
during sendto().
The socket was opened in blocking mode, so the send could sleep instead
of returning EAGAIN. Because this was the wpa_supplicant event-loop
thread, control requests, disconnect handling, reassociation, and clean
shutdown could no longer proceed.
NetworkManager itself appeared to be in normal poll() and futex() waits
rather than blocked in the same kernel path.
Recovery succeeded with:
sudo systemctl restart wpa_supplicant NetworkManager
After the restart, iw showed a valid association and:
wpa_state=COMPLETED
No reboot or USB unbind was required for this occurrence.
I am attaching a single archive:
Jul24-logs.zip
It contains the relevant journals, live hang captures, matching strace,
packet-socket state, fd-to-inode mapping, the diagnostic script, and the
post-recovery state.
I am not claiming yet that mt7921u is definitively the root cause, that
the reason-252 disassociation caused the block, or that this is
necessarily the same root cause as the earlier USB-unbind teardown
deadlock. The new evidence shows that, during this occurrence,
wpa_supplicant became blocked in the kernel packet-send path while
NetworkManager retained stale connected state.
** Attachment added: "Jul24-logs.zip"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161448/+attachment/5986115/+files/Jul24-logs.zip
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2161448
Title:
mt7921u: USB Wi-Fi enters unrecoverable state after prolonged uptime;
NetworkManager/supplicant stalls followed by USB disconnect deadlock
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161448/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
