Other Parts Discussed in Thread: WL1271, TCA6408, WL1837, WL1831
Running under Linux kernel 5.4 on embedded device (Xilinx Zynq 7020, armhf), Ubuntu 20.04.3 LTS.
After operating properly for several days, my WiFi connection dropped, and syslog showed these messages:
Nov 02 15:02:03 MPM4-6001 kernel: wl1271_sdio mmc1:0001:2: sdio write failed (-110)
Nov 02 15:02:03 MPM4-6001 kernel: wlcore: WARNING Enable for recovery failed
Nov 02 15:02:03 MPM4-6001 kernel: wlcore: down
Nov 02 15:02:03 MPM4-6001 kernel: wlcore: down
Nov 02 15:02:03 MPM4-6001 kernel: ieee80211 phy0: Hardware restart was requested
Nov 02 15:02:04 MPM4-6001 kernel: wl1271_sdio mmc1:0001:2: wl12xx_sdio_power_on: failed to get_sync(-110)
Nov 02 15:02:04 MPM4-6001 kernel: wl1271_sdio mmc1:0001:2: wl12xx_sdio_power_on: failed to get_sync(-22)
Nov 02 15:02:04 MPM4-6001 kernel: wl1271_sdio mmc1:0001:2: wl12xx_sdio_power_on: failed to get_sync(-22)
Nov 02 15:02:04 MPM4-6001 kernel: wlcore: ERROR firmware boot failed despite 3 retries
Nov 02 15:02:04 MPM4-6001 kernel: wlan0: deauthenticating from c0:36:53:73:00:85 by local choice (Reason: 3=DEAUTH_LEAVING)
Nov 02 15:02:04 MPM4-6001 kernel: wlan0: HW problem - can not stop rx aggregation for c0:36:53:73:00:85 tid 0
Nov 02 15:02:04 MPM4-6001 kernel: wlan0: HW problem - can not stop rx aggregation for c0:36:53:73:00:85 tid 1
Nov 02 15:02:04 MPM4-6001 kernel: wlan0: HW problem - can not stop rx aggregation for c0:36:53:73:00:85 tid 6
Nov 02 15:02:04 MPM4-6001 kernel: wlan0: failed to remove key (0, c0:36:53:73:00:85) from hardware (-5)
Nov 02 15:02:04 MPM4-6001 kernel: wlan0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-5)
Nov 02 15:02:04 MPM4-6001 kernel: wlan0: failed to remove key (2, ff:ff:ff:ff:ff:ff) from hardware (-5)
Nov 02 15:02:04 MPM4-6001 wpa_supplicant[229]: wlan0: CTRL-EVENT-DISCONNECTED bssid=c0:36:53:73:00:85 reason=3 locally_generated=1
Nov 02 15:02:04 MPM4-6001 avahi-daemon[251]: Interface wlan0.IPv6 no longer relevant for mDNS.
Nov 02 15:02:04 MPM4-6001 avahi-daemon[251]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fd99:242a:99b6:1:3ea3:8ff:fec2:9407.
Nov 02 15:02:04 MPM4-6001 systemd-networkd[197]: wlan0: Link DOWN
Nov 02 15:02:04 MPM4-6001 avahi-daemon[251]: Interface wlan0.IPv4 no longer relevant for mDNS.
Nov 02 15:02:04 MPM4-6001 wpa_supplicant[229]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Nov 02 15:02:04 MPM4-6001 avahi-daemon[251]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 192.168.4.103.
Nov 02 15:02:04 MPM4-6001 avahi-daemon[251]: Withdrawing address record for 2600:1700:e320:48df:3ea3:8ff:fec2:9407 on wlan0.
Nov 02 15:02:04 MPM4-6001 avahi-daemon[251]: Withdrawing address record for fd99:242a:99b6:1:3ea3:8ff:fec2:9407 on wlan0.
Nov 02 15:02:04 MPM4-6001 avahi-daemon[251]: Withdrawing address record for 192.168.4.103 on wlan0.
Nov 02 15:02:04 MPM4-6001 systemd-networkd[197]: wlan0: Lost carrier
Nov 02 15:02:04 MPM4-6001 systemd-networkd[197]: wlan0: DHCP lease lost
- WL_EN goes low
- Network interface (wlan0) no longer appears in output of "ip link"
- wlan0 disappears from /sys/class/net
- phy0 disappears from /sys/kernel/debug/ieee80211
- cat /sys/class/net/wlan0/device/power/runtime_status returns "failed".
Rebooting does not recover from this condition - only removing power from the device returns normal operation.
WL_EN goes high momentarily during reboot, then returns low.
Normal (before failure) boot shows these messages in syslog:
Mar 2 12:58:11 localhost systemd-modules-load[147]: Inserted module 'wl18xx'
Mar 2 12:58:11 localhost kernel: [ 9.102380] wl18xx_driver wl18xx.0.auto: Direct firmware load for ti-connectivity/wl1271-nvs.bin failed with error -2
Mar 2 12:58:11 localhost kernel: [ 9.638664] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
Mar 2 12:58:11 localhost kernel: [ 9.657138] wlcore: loaded
Mar 2 12:58:11 localhost kernel: [ 12.261223] wlcore: PHY firmware version: Rev 8.2.0.0.236
Mar 2 12:58:11 localhost kernel: [ 12.361951] wlcore: firmware booted (Rev 8.9.0.0.69)
This happens irregularly, but frequently, with days passing between failures. Needless to say this is a catastrophic failure, requiring an in-person visit to the device's location in order to "turn it off and back on again." Not a good look.
Any help would be appreciated.