Hi All,
I noticed that sometime I see the kernel trace while system enters into
suspend. The trace log is attached with this email.
>From the kernel trace it appears that mwifiex_cancel_all_pending_cmd()
function tries to cancel the current command by invoking
mwifiex_complete_cmd(). Just before calling this routine, the
adapter->curr_cmd->wait_q_enabled is set to false. And there is a
WARN_ON() in the mwifiex_complete_cmd() routine on this variable being
false, because this condition will always evaluate to true.
I think by setting the wait_q_enabled flag to false after calling the
mwifiex_complete_cmd() should fix this problem. I have attached the
patch for the same, however I am not sure if that is the right way to
fix this issue. If there is any better way to fix it, please suggest.
Thanks,
Vishal
Hi Vishal,
2016-04-07 15:02 GMT+02:00 Vishal Thanki <[email protected]>:
> Hi All,
>
> I noticed that sometime I see the kernel trace while system enters into
> suspend. The trace log is attached with this email.
>
> From the kernel trace it appears that mwifiex_cancel_all_pending_cmd()
> function tries to cancel the current command by invoking
> mwifiex_complete_cmd(). Just before calling this routine, the
> adapter->curr_cmd->wait_q_enabled is set to false. And there is a
> WARN_ON() in the mwifiex_complete_cmd() routine on this variable being
> false, because this condition will always evaluate to true.
thanks for the analysis.
tested-by: [email protected]
>
> I think by setting the wait_q_enabled flag to false after calling the
> mwifiex_complete_cmd() should fix this problem. I have attached the
> patch for the same, however I am not sure if that is the right way to
> fix this issue. If there is any better way to fix it, please suggest.
>
> Thanks,
> Vishal
On Thu, Apr 7, 2016 at 11:12 PM, Andreas Fenkart <[email protected]> wrote:
> Hi Vishal,
>
> 2016-04-07 15:02 GMT+02:00 Vishal Thanki <[email protected]>:
>> Hi All,
>>
>> I noticed that sometime I see the kernel trace while system enters into
>> suspend. The trace log is attached with this email.
>>
>> From the kernel trace it appears that mwifiex_cancel_all_pending_cmd()
>> function tries to cancel the current command by invoking
>> mwifiex_complete_cmd(). Just before calling this routine, the
>> adapter->curr_cmd->wait_q_enabled is set to false. And there is a
>> WARN_ON() in the mwifiex_complete_cmd() routine on this variable being
>> false, because this condition will always evaluate to true.
>
> thanks for the analysis.
> tested-by: [email protected]
>
Thanks for the feedback. Should I submit the patch as a separate email?
Vishal