> > * Tony Lindgren <[email protected]> [180605 04:22]:
> > > * Reizer, Eyal <[email protected]> [180603 06:07]:
> > > > I have noticed the following recovery a couple of times on my setup
> > when the board was
> > > > just sitting for a long time with just pings
> > > > It starts with a firmware recovery started from the interrupt handl=
er
> but
> > the recovery fails
> > >
> > > Sounds like the recovery needs some more work :)
> > >
> > > > leaving the sdio stuck.
> > > > At this stage the only way to get out of it is unload/load of the d=
river
> > modules.
> > > > Have you seen this on your side as well?
> > >
> > > Hmm I don't think I've seen this one yet.
> > >
> > > > 64 bytes from 192.168.100.1: seq=3D32772 ttl=3D64 time=3D9.644 ms
> > > > 64 bytes from 192.168.100.1: seq=3D32773 ttl=3D64 time=3D9.572 ms
> > > > 64 bytes from 192.168.100.1: seq=3D32774 ttl=3D64 time=3D10.974 ms
> > > > 64 bytes from 192.168.100.1: seq=3D32775 ttl=3D64 time=3D9.618 ms
> > > > [127899.040526] wlcore: ERROR SW watchdog interrupt received!
> starting
> > recovery.
> > >
> > > Do you know what does the SW watchdog means here? Does it mean the
> > > interrupt did not get delivered to wlcore? Or a spurious IRQ to wlcor=
e?
> > > Or a timeout waiting for the ELP wake interrupt?
> >
> > Also, can you check if patch "[RFT 7/6] wlcore: Make sure firmware is
> > initialized
> > in wl1271_op_add_interface()" already fixes this issue if you did not h=
ave it
> > already applied?
> >
> Sure will do. The firmware that showed this issue has some extra debuggin=
g
> info
> Enabled in it and this may have been the cause of the recovery (Infernal
> logging error).
> The fact that it didn't recover was the issue itself. I am now running wi=
th the
> latest's
> firmware 8.9.0.0.78 and will see if I can still replicate it.
> If I see it, I will try applying patch 7 and see if it helps. Right now I=
don't yet
> have
> It applied.
>=20
Latest wl18xx firmware was running fine for two days without the crash, so =
it was indeed just a logging issue in this case.
However, trying a wl1281 module and enabling PLT mode it boots ok but after=
a couple of seconds the below crash is seen.
Seems like a similar crash to the one I have seen before,right?
I do have patch 7/6 applied now.
sh-4.4# calibrator wlan0 plt power_mode on
[ 57.198492] wlcore: power up
[ 57.757871] wlcore: firmware booted in PLT mode PLT_ON (PLT 7.3.10.2.142=
)
sh-4.4#
sh-4.4#
sh-4.4# ca[ 86.485020] ------------[ cut here ]------------
[ 86.490334] WARNING: CPU: 0 PID: 502 at drivers/net/wireless/ti/wlcore/m=
ain.c:806 wl12xx_queue_recovery_work+0x64/0x6c [wlcore]
[ 86.502047] Modules linked in: arc4 pru_rproc wl12xx pruss_intc wlcore m=
ac80211 cfg80211 pruss ti_am335x_tsc ti_am335x_adc musb_dsps musb_hdrc udc_=
core usbcore phy_am335x phy_generic phy_am335x_control usb_common pm33xx wk=
up_m3_ipc snd_soc_simple_card snd_soc_simple_card_utils wkup_m3_rproc remot=
eproc omap_aes_driver crypto_engine omap_sham omap_crypto ti_emif_sram prus=
s_soc_bus snd_soc_tlv320aic3x wlcore_sdio matrix_keypad rtc_omap ti_am335x_=
tscadc omap_wdt matrix_keymap musb_am335x sch_fq_codel
[ 86.546686] CPU: 0 PID: 502 Comm: irq/71-wl12xx Not tainted 4.14.40-0141=
5-g47241db-dirty #119
[ 86.555312] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 86.561540] Backtrace:
[ 86.564119] [<c010baf8>] (dump_backtrace) from [<c010bd5c>] (show_stack+=
0x18/0x1c)
[ 86.571838] r6:00000000 r5:bf30a5fc r4:00000000 r3:00000000
[ 86.577661] [<c010bd44>] (show_stack) from [<c0805dd0>] (dump_stack+0x20=
/0x28)
[ 86.584994] [<c0805db0>] (dump_stack) from [<c01287bc>] (__warn+0xdc/0x1=
04)
[ 86.592121] [<c01286e0>] (__warn) from [<c012880c>] (warn_slowpath_null+=
0x28/0x30)
[ 86.599838] r10:c0d4ea79 r8:c0169590 r7:db0f1558 r6:dc716ec8 r5:dc716d3=
8 r4:dc716d00
[ 86.608019] [<c01287e4>] (warn_slowpath_null) from [<bf2f5468>] (wl12xx_=
queue_recovery_work+0x64/0x6c [wlcore])
[ 86.618630] [<bf2f5404>] (wl12xx_queue_recovery_work [wlcore]) from [<bf=
2f5a18>] (wlcore_irq+0x21c/0x234 [wlcore])
[ 86.629157] r4:dc716d00 r3:db164010
[ 86.633009] [<bf2f57fc>] (wlcore_irq [wlcore]) from [<c01695b4>] (irq_th=
read_fn+0x24/0x3c)
[ 86.641441] r7:db0f1558 r6:db0f1500 r5:00000001 r4:db1b8680
[ 86.647236] [<c0169590>] (irq_thread_fn) from [<c0169260>] (irq_thread+0=
x10c/0x1ec)
[ 86.655044] r6:db0f1500 r5:00000001 r4:db1b8680 r3:db623600
[ 86.660875] [<c0169154>] (irq_thread) from [<c014526c>] (kthread+0x11c/0=
x154)
[ 86.668148] r10:c0169154 r8:db1b8680 r7:db1b8958 r6:db1b8600 r5:0000000=
0 r4:db1b8940
[ 86.676104] [<c0145150>] (kthread) from [<c0107f68>] (ret_from_fork+0x14=
/0x2c)
[ 86.683479] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:0000000=
0 r5:c0145150
[ 86.691451] r4:db1b8600 r3:ffffffff
[ 86.695099] ---[ end trace dea7def5777109c9 ]---
BR,
Eyal
Hi,
* Reizer, Eyal <[email protected]> [180606 05:22]:
> Latest wl18xx firmware was running fine for two days without the crash, so it was indeed just a logging issue in this case.
OK good to hear.
> However, trying a wl1281 module and enabling PLT mode it boots ok but after a couple of seconds the below crash is seen.
> Seems like a similar crash to the one I have seen before,right?
Sorry for the delay, only today had enough time to figure
this one out, see below.
> sh-4.4# calibrator wlan0 plt power_mode on
> [ 57.198492] wlcore: power up
> [ 57.757871] wlcore: firmware booted in PLT mode PLT_ON (PLT 7.3.10.2.142)
> sh-4.4#
> sh-4.4#
> sh-4.4# ca[ 86.485020] ------------[ cut here ]------------
> [ 86.490334] WARNING: CPU: 0 PID: 502 at drivers/net/wireless/ti/wlcore/main.c:806
This happens on runtime_suspend() where we are already in PLT
and then that error gets stored and then next pm_runtime_get()
returns -EINVAL. The patch below should fix it. I'll fold it
into the runtime PM related patch assuming it works for you.
Regards,
Tony
8< -------
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -6677,7 +6677,7 @@ static int __maybe_unused wlcore_runtime_suspend(struct device *dev)
/* We do not enter elp sleep in PLT mode */
if (wl->plt)
- return -EINVAL;
+ return 0;
/* Nothing to do if no ELP mode requested */
if (wl->sleep_auth != WL1271_PSM_ELP)