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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
