WPA supplicant hangs on shutdown

ARM Technical Assistance
1

As mentioned in title.
Basically, since the last update, shutdown hangs for over 9 minutes trying to stop wpa_supplicant. Google turns up similar issues which were resolved with kernel updates, which isn’t going to work for me right now. I’ve tried to stop wpa_supplicant.service while the system is running, and that also hangs.

Mar 26 06:09:35 neurofire systemd[1]: wpa_supplicant.service: Unit process 925 (wpa_supplicant) remains running after unit stopped.
Mar 26 06:09:35 neurofire systemd[1]: wpa_supplicant.service: Failed with result 'timeout'.
Mar 26 06:09:35 neurofire systemd[1]: wpa_supplicant.service: Processes still around after final SIGKILL. Entering failed mode.

[aurion@neurofire ~]$ inxi -GSC -xx
System:    Host: neurofire Kernel: 5.12.0-rc3-1-MANJARO-ARM aarch64 bits: 64 compiler: gcc v: 10.2.0 
           Desktop: KDE Plasma 5.21.3 tk: Qt 5.15.2 wm: kwin_x11 dm: startx Distro: Manjaro ARM 
CPU:       Info: 6-Core (2-Die) model: N/A variant-1: cortex-a53 variant-2: cortex-a73 bits: 64 type: MCP MCM arch: ARMv8 
           rev: 4 
           features: Use -f option to see features bogomips: 0 
           Speed: 2208 MHz min/max: 100/1800:2208 MHz Core speeds (MHz): 1: 1800 2: 1800 3: 2208 4: 2208 5: 2208 6: 2208 
Graphics:  Device-1: meson-g12a-mali driver: panfrost v: kernel bus ID: N/A chip ID: amlogic:ffe40000 
           Device-2: meson-g12a-dw-hdmi driver: meson_dw_hdmi v: kernel bus ID: N/A chip ID: amlogic:ff600000 
           Display: server: X.org 1.20.10 compositor: kwin_x11 driver: modesetting alternate: fbdev 
           resolution: <xdpyinfo missing> 
           OpenGL: renderer: Mali G52 (Panfrost) v: 3.1 Mesa 21.1.0-devel (git-1b3a0f8829) direct render: Yes 

[aurion@neurofire ~]$ systemctl status wpa_supplicant
● wpa_supplicant.service - WPA supplicant
     Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; disabled; vendor preset: disabled)
     Active: active (running) since Sun 2021-04-04 19:33:29 EDT; 15min ago
   Main PID: 1707 (wpa_supplicant)
      Tasks: 1 (limit: 4256)
     Memory: 4.0M
     CGroup: /system.slice/wpa_supplicant.service
             └─1707 /usr/bin/wpa_supplicant -u -s -O /run/wpa_supplicant

Apr 04 19:33:29 neurofire systemd[1]: Started WPA supplicant.
Apr 04 19:33:29 neurofire wpa_supplicant[1707]: rfkill: Cannot get wiphy information
Apr 04 19:33:29 neurofire wpa_supplicant[1707]: rfkill: Cannot get wiphy information
Apr 04 19:33:31 neurofire wpa_supplicant[1707]: wlan0: WPS-PBC-ACTIVE
Apr 04 19:33:38 neurofire wpa_supplicant[1707]: wlan0: Reject scan trigger since one is already pending
Apr 04 19:34:13 neurofire wpa_supplicant[1707]: wlan0: WPS-PBC-ACTIVE
Apr 04 19:34:18 neurofire wpa_supplicant[1707]: wlan0: Trying to associate with SSID 'mywifi'
Apr 04 19:34:18 neurofire wpa_supplicant[1707]: wlan0: Associated with xx:xx:xx:xx:xx:xx
Apr 04 19:34:18 neurofire wpa_supplicant[1707]: wlan0: CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed [id=0 id>
Apr 04 19:34:18 neurofire wpa_supplicant[1707]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
2

Guessing you have not been following the “New Raspberry Pi Kernels & Related Packages” thread. Kernel 5.12 has been doing that ever since it came out. They just fixed it a few days ago.

Added:

Sorry about that. I thought you had a pi4 but saw your number of cores. There is a fix but I do not do your kernel.

RPi already pulled the patch from upstream to fix it:

https://lore.kernel.org/linux-wireless/20210313143635.109154-1-hdegoede@redhat.com/

1 Like
3

I’m pretty sure @spikerguy does your kernel.

1 Like
4

@neurofire

I posted a temp fix here before the pi people fixed their kernel:

https://forum.manjaro.org/t/new-raspberry-pi-kernels-related-packages/4721/510

1 Like
5

Thank you so much, I’ll try it out.

6

Please share which device are you using.
Can you share the kernel pkg used ? From the inxi I see 5.12.0-rc3 which is linux-rc though.

7