wlan: Address deadlock between rmmod thread and Tx thread during unload
During rmmod HALDUMP command is posted to TX thread to free the
BTQM queues, after which rmmod thread post a message to WDA queue
by taking the mutex lock. Meanwhile the TX thread is scheduled and
tries to process HALDUMP command, the same will wait on mutex_lock
which is hold by rmmod thread. As a part of WDA STOP rmmod thread
tries to stop transport driver by posting WDTS_POWER_STATE_DOWN command
to firmware, as a response to same command ack is received by RX thread
in dxeRxThreadSetPowerStateEventHandler and same is posted to TX
thread which is blocked on mutex lock held by rmmod thread results
in dead lock.
To mitigate this issue, donot post HALDUMP command to TX Thread
instead call directly vos API to issue dump command to firmware.
Change-Id: I75e9b559acbc1b6d9c5edf32614d3fd63c4411e0
CRs-Fixed: 806088
diff --git a/CORE/HDD/src/wlan_hdd_main.c b/CORE/HDD/src/wlan_hdd_main.c
index 5960440..414557b 100755
--- a/CORE/HDD/src/wlan_hdd_main.c
+++ b/CORE/HDD/src/wlan_hdd_main.c
@@ -8163,8 +8163,7 @@
{
/* This will issue a dump command which will clean up
BTQM queues and unblock MC thread */
- WLANTL_TLDebugMessage(WLANTL_DEBUG_FW_CLEANUP);
-
+ vos_fwDumpReq(274, 0, 0, 0, 0, 1);
// Unloading, restart logic is no more required.
wlan_hdd_restart_deinit(pHddCtx);