Hi Tim,
> Bing,
>
> I am trying to figure out if this patch would help in the situation I
> told you about in September.
>
> I was doing suspend/resume testing using
>
> rtcwake -s 6 -mmem
>
> in a loop to test the ability of the mwifiex driver to suspend/resume.
>
> I was seeing sporadic failures (wedgeups), and the majority of those
> failures I saw printed the printouts in mwifiex_cmd_timeout_func with
> cmd = 0xe5 which is CMD_802_11_HS_CFG_ENH. When this happens, two
> minutes later I get notified that the rtcwake thread is blocked, like
> this:
>
> INFO: task rtcwake:3495 blocked for more than 120 seconds.
>
>
>
> I believe the hang happens when mwifiex_sdio_suspend() is called in
> the rtcwake thread it winds winds up blocked waiting on a wait queue
> in mwifiex_enable_hs() because when the timeout happens it never gets
> woken up.
You can try it with an asynchronous call.
diff --git a/drivers/net/wireless/mwifiex/sta_ioctl.c b/drivers/net/wireless/mwi
index c8b50c7..704d344 100644
--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -472,7 +472,7 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
if (mwifiex_set_hs_params(mwifiex_get_priv(adapter,
MWIFIEX_BSS_ROLE_STA),
- HostCmd_ACT_GEN_SET, MWIFIEX_SYNC_CMD,
+ HostCmd_ACT_GEN_SET, MWIFIEX_ASYNC_CMD,
&hscfg)) {
dev_err(adapter->dev, "IOCTL request HS enable failed\n");
return false;
If this doesn't help, please apply the debug patch attached. Hopefully we can get some useful information.
Thanks,
Bing
>
> Reading your patch today, I don't see how your patch will add a new
> way to get that hung thread unblocked.
>
> (I'm also not sure doing the reset of the card will work properly while
> the system is in the middle of trying to suspend, but that's a
> different question.)
>
> If I'm missing a clue about this, please let me know.
>
>
> -Tim Shepard
> shep@xxxxxxxxxx
Attachment:
mwifiex_v3.7rc3_debug_suspend_resume.diff
Description: mwifiex_v3.7rc3_debug_suspend_resume.diff
