SailfishX WiFi firmware crash
Update April 4th 2020 The issue is still not solved in SFOS 3.3.0.14 Rokua. Enabling AP/band steering features in my Fritzbox causes my Xperia X to loose connectivity within a few minutes if I move between access points. In this case, a soft reset (power + volume up) is necessary. To be honest, I don't understand why this serious issue has no "tracked by Jolla" label.
Update: I think I found an avoidable trigger of the firmware crash: It's one of the 802.11 assisted roaming extensions (most likely k or v, but couldn't rule out r yet [and won't investigate further]). Since the crash hasn't happened last week, when I had used a different BSSID, I looked for the differences and disable k+v assisted roaming for the new BSSID on all access points (see https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/Chapter-11.pdf for example, seems to be a good overview).
So far, no crash anymore (about 4 hours medium WiFi usage). Will report if I observe another crash despite disabled 802.11/k/v.
Thanks for your comments, obviously I'm not the only one suffering from that issue. Maybe you can look if your environment also provides assisted roaming extensions and if disabling is possible and helps?
Original question from 2019-05-13:
Hello, the following happens after unpredictable (time+volume wise) WiFi usage on my Xperia X with Hossa using 2.4GHz, WPA2:
Mai 13 09:03:51 phony mce[626]: tklock.c: tklock_dbus_notification_end_cb(): notification end from name=:1.28 owner=:1.28 pid=1253 uid=100000 gid=999 priv=1 cmd=/usr/bin/lipstick -plugin evdevtouch:/dev/touchscreen -plugin e
… kernel: INTERNAL ERROR: FIRMWARE HALTED : set BUS DOWN
… kernel: CONSOLE: 475 wlc_rrm_stop: abort rrm processing
… kernel: CONSOLE: 002890.475 wlc_rrm_abort: state upd to 1
… kernel: CONSOLE: 002890.475 wlc_rrm_abort: state upd to 0
… phony kernel: CONSOLE: 002890.475 wlc_rrm_bcnreq_scancb: state: 0, status: 4
… kernel: CONSOLE: 002890.475
… kernel: CONSOLE: FWID 01-75cc3c71
… kernel: CONSOLE: flags 1
… kernel: CONSOLE: 002890.475
… kernel: CONSOLE: TRAP 4(25f828): pc 7a094, lr 7a093, sp 25f880, cpsr 6000019f, spsr 600001bf
… kernel: CONSOLE: 002890.475 dfsr 80d, dfar 218
… kernel: CONSOLE: 002890.475 r0 36, r1 5, r2 0, r3 1, r4 24a5cc, r5 0, r6 24a55c
… kernel: CONSOLE: 002890.475 r7 4, r8 259e38, r9 4, r10 24a5cc, r11 f, r12 0
… kernel: CONSOLE: 002890.475
… kernel: CONSOLE: sp+0 00256bf4 00259e38 0007a079 00000000
… kernel: CONSOLE: 002890.475 sp+10 0021dbec 001e5f1d 00256bf4 00256bc4
… kernel: CONSOLE:
… kernel: CONSOLE: 002890.475 sp+8 0007a079
… kernel: CONSOLE: 002890.475 sp+14 001e5f1d
… kernel: CONSOLE: 002890.475 sp+34 001e682b
… kernel: CONSOLE: 002890.475 sp+3c 00079dff
… kernel: CONSOLE: 002890.475 sp+64 00029c91
… kernel: CONSOLE: 002890.476 sp+7c 00031793
… kernel: CONSOLE: 002890.476 sp+a8 00029c91
… kernel: CONSOLE: 002890.476 sp+d8 00005c1b
… kernel: CONSOLE: 002890.476 sp+fc 00023f3b
… kernel: CONSOLE: 002890.476 sp+128 00029c91
… kernel: CONSOLE: 002890.476 sp+150 00020023
… kernel: CONSOLE: 002890.476 sp+19c 0002ffff
… kernel: CONSOLE: 002890.476 sp+1b0 00020023
… kernel: CONSOLE: 002890.476 sp+1dc 0002c4af
… kernel: CONSOLE: 002890.476 sp+1f8 0000018b
… kernel: CONSOLE: 002890.476 sp+1fc 00036a71
… kernel: dhdsdio_checkdied: msgtrace address : 0x00000000
console address : 0x0025DEBC
Assrt not built in dongle
Dongle trap type 0x4 @ epc 0x7a094, cpsr 0x6000019f, spsr 0x600001bf, sp 0x25f880,lp 0x7a093, rpc 0x7a094 Trap offset 0x25f828, r0 0x36, r1 0x5, r2 0x0, r3 0x1, r4 0x24a5cc, r5 0x0, r6 0x24a55c, r7 0x4
Afterwards, anything network related hangs, including D-Bus / systemctld. So I cannot shutdown the phone anymore! Shutdown sequence starts but never finishes (~60% battery drain over night after leaving in shutdown-sequence). Fortunately, the fastboot-keys do reset the phone! (Vol+&Power – thought my phone is dead since I cannot remove the battery, but found out accidentally) After the reset, the above quoted journalctl isn't shown – like mentioned, even the shutdown sequence doesn't succeed after the WiFi firmware crash. Also 'ifconfig' only hangs.
So two issues here: The firmware crash itself and the failure handling of the former. Unfortunately I don't know much about the Sailfish X architecture, but as far as I read, the firmware is inherited from partitions populated by vendor android distribution. Which would mean, the version I had installed before flashing Sailfish X control the hardware, right? In order to use different driver/firmware, one has to re-flash with vendor (Sony) image, right? (and then additionally Sailfish X again, which isn't a really bisecting friendly procedure, but flash wearing…)
Has anybody else seen WiFi firmware crashes starting with a specific Android base image version? I used the latest 8, afair.
Something similar happened to me until 3.0.2 but went away with 3.0.3. I even bought an XA2 Plus believing my X had died.
Giacomo Di Giacomo ( 2019-05-13 11:11:12 +0200 )editI have experienced the described behaviour two or three times since upgrading my Xperia X to 3.0.3 Hossa, but without such deep analysis as yours.
What makes things worse is that I configured the Situations app to switch Wifi depending on my current location (at home: Wifi on). Yesterday I found several hanging connmanctl processes (originating from such switching attempts), without being able to kill them.
ziellos ( 2019-05-13 14:23:32 +0200 )editJust to prove myself wrong, the hangup happened again today. It happened much more often earlier though.
Giacomo Di Giacomo ( 2019-05-13 16:56:52 +0200 )editI've experienced the same problem recently in Rome airport with my Xperia X too but XA2 worked fine.
velemas ( 2019-05-13 17:33:28 +0200 )editI've the same Problem with my Xperia X with Sailfish 3.0.3.10. I use a AVM Fritz!Box 7490 and a 1750E Repeater. Since last week, AVM added new feature access point steering per firmware update, it uses 802.11k and v wifi extensions for that. Now my XperiaX is crashing reproducable from time to time, when it's connect to wifi. If I disable the AP steering feature, it don't crash.
jumPM ( 2019-06-06 21:15:11 +0200 )edit