Intel wifi: Pick up fixes up for 0xA5A5A5A2 in driver/firmware dumps. |
||||||||||
Issue descriptionOS Version: Chrome OS - R60 + cherry-pick to R59. Intel wifi firmware dumps, being chased/root-caused on several devices[1],often have 0xA5A5A5A2 instead of the true register values. Intel has provided two potential fixes, this bug tracks the testing and cherry-picking to R59. [1] https://b.corp.google.com/issues/37920902 and https://b.corp.google.com/issues/37544587
,
May 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f51ebfdaf289a6d70747b2a4aafccb8cde58e6e3 commit f51ebfdaf289a6d70747b2a4aafccb8cde58e6e3 Author: Luca Coelho <luciano.coelho@intel.com> Date: Wed May 24 05:17:49 2017 CHROMIUM: iwl7000: mvm: reset the HW before dumping if HW error is detected If the hardware is stuck, we can't read any of the memory we need to dump it, so we end up printing only 0xa5a5a5a5, which is useless. To solve this, poke the hardware by triggering a reset and re-enabling the clocks if we detect a HW error. Additionally, for this to work, remove unnecessary bh protection when calling the dump functions, so we can sleep to wait for the register writes. This is a combination of two patches from the iwl7000-tree. BUG=b:37920902, chromium:719261 TEST=Run continuous connect/disconnect cycles Change-Id: If7eec4a60eee806ac63198832193c116b22697ba Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: 054fad500f7398f18ea447778bc38f5361fedc5a iwl7000-tree: 47e688654d273b8d7ba5ee963ba9a8a3674952de Reviewed-on: https://chromium-review.googlesource.com/497391 Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 67d059fab8965fd1ac3af4ad9a4cb4037959dfcd) Reviewed-on: https://chromium-review.googlesource.com/513488 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/f51ebfdaf289a6d70747b2a4aafccb8cde58e6e3/drivers/net/wireless/iwl7000/iwlwifi/pcie/rx.c [modify] https://crrev.com/f51ebfdaf289a6d70747b2a4aafccb8cde58e6e3/drivers/net/wireless/iwl7000/iwlwifi/mvm/utils.c
,
May 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b329357377c548b06c16f6ca7da6bdf6c476b8e1 commit b329357377c548b06c16f6ca7da6bdf6c476b8e1 Author: Luca Coelho <luciano.coelho@intel.com> Date: Wed May 24 05:20:46 2017 CHROMIUM: iwl7000: mvm: reset the HW before dumping if HW error is detected If the hardware is stuck, we can't read any of the memory we need to dump it, so we end up printing only 0xa5a5a5a5, which is useless. To solve this, poke the hardware by triggering a reset and re-enabling the clocks if we detect a HW error. Additionally, for this to work, remove unnecessary bh protection when calling the dump functions, so we can sleep to wait for the register writes. This is a combination of two patches from the iwl7000-tree. BUG=b:37920902, chromium:719261 TEST=Run continuous connect/disconnect cycles Change-Id: If7eec4a60eee806ac63198832193c116b22697ba Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: 054fad500f7398f18ea447778bc38f5361fedc5a iwl7000-tree: 47e688654d273b8d7ba5ee963ba9a8a3674952de Reviewed-on: https://chromium-review.googlesource.com/513489 Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/b329357377c548b06c16f6ca7da6bdf6c476b8e1/drivers/net/wireless-3.8/iwl7000/iwlwifi/pcie/rx.c [modify] https://crrev.com/b329357377c548b06c16f6ca7da6bdf6c476b8e1/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/utils.c
,
May 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9490d46259e49dd4607fe9f893fe69a5c069b406 commit 9490d46259e49dd4607fe9f893fe69a5c069b406 Author: Liad Kaufman <liad.kaufman@intel.com> Date: Wed May 24 19:55:22 2017 CHROMIUM: iwl7000: mvm: fix fw monitor 7000 HW recollecting To stop and start the FW monitor in the 7000 HW family we need to use a different bit, otherwise after stopping it for the first time - it won't get restarted. Use the correct bitmask. Note: This fix is only for DRAM collection mode. For other modes, an additional fix will be needed. BUG= chromium:719261 TEST=None Change-Id: Ie2176d0310bb41b604446f02f313c560574430a9 Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> iwl7000-tree: 9e5eb21aa386b3364d2afc3747ad1635e55dd7a9 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Previous-Reviewed-on: https://chromium-review.googlesource.com/497750 (cherry picked from commit 1917397efd65b035393c9093e4eca1e0704357b1) Reviewed-on: https://chromium-review.googlesource.com/513592 Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/9490d46259e49dd4607fe9f893fe69a5c069b406/drivers/net/wireless/iwl7000/iwlwifi/mvm/ops.c
,
May 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8d25fb98a087ed8343bc64cec3e13307483e9230 commit 8d25fb98a087ed8343bc64cec3e13307483e9230 Author: Luca Coelho <luciano.coelho@intel.com> Date: Wed May 24 19:55:27 2017 CHROMIUM: iwl7000: mvm: reset the HW before dumping if HW error is detected If the hardware is stuck, we can't read any of the memory we need to dump it, so we end up printing only 0xa5a5a5a5, which is useless. To solve this, poke the hardware by triggering a reset and re-enabling the clocks if we detect a HW error. Additionally, for this to work, remove unnecessary bh protection when calling the dump functions, so we can sleep to wait for the register writes. This is a combination of two patches from the iwl7000-tree. BUG=b:37920902, chromium:719261 TEST=Run continuous connect/disconnect cycles Change-Id: If7eec4a60eee806ac63198832193c116b22697ba Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: 054fad500f7398f18ea447778bc38f5361fedc5a iwl7000-tree: 47e688654d273b8d7ba5ee963ba9a8a3674952de Previous-Reviewed-on: https://chromium-review.googlesource.com/497751 (cherry picked from commit e138ff298bd4043d17a5ae4523a1e1bb6f054c02) Reviewed-on: https://chromium-review.googlesource.com/514206 Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/8d25fb98a087ed8343bc64cec3e13307483e9230/drivers/net/wireless/iwl7000/iwlwifi/pcie/rx.c [modify] https://crrev.com/8d25fb98a087ed8343bc64cec3e13307483e9230/drivers/net/wireless/iwl7000/iwlwifi/mvm/utils.c
,
May 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/73f56a1fcdd39ca9e5224d75d385505f8a54787c commit 73f56a1fcdd39ca9e5224d75d385505f8a54787c Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Wed May 24 19:55:32 2017 CHROMIUM: iwl7000: mvm: fix the recovery flow while connecting In BSS mode in the disconnection flow, mac80211 removes the AP station before the vif is set to unassociated. Our firmware wants it the other way around: first set the vif as unassociated, and then remove the AP station. In order to bridge between those two different behaviors, iwlmvm doesn't remove the station from the firmware when mac80211 removes it, but only after the vif is set to unassociated. The implementation is in iwl_mvm_bss_info_changed_station: if (assoc state was modified && mvmvif->ap_sta_id is VALID && assoc state is now UNASSC) remove_the_station_from_the_firmware() During the recovery flow, mac80211 re-adds the AP station and then reconfigures the vif. Since the vif is not associated, and then, we enter the if above (which was intended to be taken in the disconnection flow only) and remove the station we just added. This defeats the recovery flow. Fix this by not removing the AP station in this flow if we are in recovery flow. BUG=b:37920902, chromium:719261 TEST=Run continuous connect/disconnect cycles Change-Id: Iaec4545022c964aaeb49619901d6cb6d45e9988e Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: 1d392aeb9aa42a8792cce52db7ef8867105f1c3b Previous-Reviewed-on: https://chromium-review.googlesource.com/497752 (cherry picked from commit 4d543412fc0bf7c880a2b6a31b6c88ad28d13605) Reviewed-on: https://chromium-review.googlesource.com/514266 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/73f56a1fcdd39ca9e5224d75d385505f8a54787c/drivers/net/wireless/iwl7000/iwlwifi/mvm/mac80211.c
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2a1d476c5fe7f7fdfc4287099bb97a844f74e852 commit 2a1d476c5fe7f7fdfc4287099bb97a844f74e852 Author: Liad Kaufman <liad.kaufman@intel.com> Date: Thu May 25 00:56:36 2017 CHROMIUM: iwl7000: mvm: fix fw monitor 7000 HW recollecting To stop and start the FW monitor in the 7000 HW family we need to use a different bit, otherwise after stopping it for the first time - it won't get restarted. Use the correct bitmask. Note: This fix is only for DRAM collection mode. For other modes, an additional fix will be needed. BUG= chromium:719261 TEST=None Change-Id: Ie2176d0310bb41b604446f02f313c560574430a9 Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> iwl7000-tree: 9e5eb21aa386b3364d2afc3747ad1635e55dd7a9 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/514430 Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/2a1d476c5fe7f7fdfc4287099bb97a844f74e852/drivers/net/wireless/iwl7000/iwlwifi/mvm/ops.c
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1c573fb3cd465b1d25f5a0e5046a4b4094e87e02 commit 1c573fb3cd465b1d25f5a0e5046a4b4094e87e02 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Thu May 25 00:56:40 2017 CHROMIUM: iwl7000: mvm: fix the recovery flow while connecting In BSS mode in the disconnection flow, mac80211 removes the AP station before the vif is set to unassociated. Our firmware wants it the other way around: first set the vif as unassociated, and then remove the AP station. In order to bridge between those two different behaviors, iwlmvm doesn't remove the station from the firmware when mac80211 removes it, but only after the vif is set to unassociated. The implementation is in iwl_mvm_bss_info_changed_station: if (assoc state was modified && mvmvif->ap_sta_id is VALID && assoc state is now UNASSC) remove_the_station_from_the_firmware() During the recovery flow, mac80211 re-adds the AP station and then reconfigures the vif. Since the vif is not associated, and then, we enter the if above (which was intended to be taken in the disconnection flow only) and remove the station we just added. This defeats the recovery flow. Fix this by not removing the AP station in this flow if we are in recovery flow. BUG=b:37920902, chromium:719261 TEST=Run continuous connect/disconnect cycles Change-Id: Iaec4545022c964aaeb49619901d6cb6d45e9988e Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: 1d392aeb9aa42a8792cce52db7ef8867105f1c3b Reviewed-on: https://chromium-review.googlesource.com/514431 Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/1c573fb3cd465b1d25f5a0e5046a4b4094e87e02/drivers/net/wireless/iwl7000/iwlwifi/mvm/mac80211.c
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/34ddcd79de5893b5fb9a2927f8087a0e80aee2b8 commit 34ddcd79de5893b5fb9a2927f8087a0e80aee2b8 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Thu May 25 20:36:16 2017 CHROMIUM: iwl7000: add a W/A for a scheduler hardware bug In case we need to move the scheduler write pointer by steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck. This leads to hardware error interrupts with status: 0x5A5A5A5A or alike. In order to work around this, detect in the transport layer that we are going to hit this case and tell iwlmvm to increment the sequence number of the packets. This allows to keep the requirement that the WiFi sequence number is in sync with the index in the scheduler Tx queue and it also allows to avoid the problematic sequence. This means that from time to time, we will start a queue from ssn + 1, but that shouldn't be a problem since we don't switch to new queues for AMPDU now that we have DQA which allows to keep the same queue while toggling the AMPDU state. This bug has been fixed on 9000 devices and up. BUG= chromium:719261 TEST=None Change-Id: Ide65c3f711ee62f17edde580fdca695f3acbf892 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> iwl7000-tree: 62d56763927c04755ee6a900b8859bd56a1c5484 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/497988 Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 2b479b821cbe68586dd48c1205a1b0000fee34f4) Reviewed-on: https://chromium-review.googlesource.com/516162 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/34ddcd79de5893b5fb9a2927f8087a0e80aee2b8/drivers/net/wireless/iwl7000/iwlwifi/pcie/tx.c [modify] https://crrev.com/34ddcd79de5893b5fb9a2927f8087a0e80aee2b8/drivers/net/wireless/iwl7000/iwlwifi/pcie/internal.h [modify] https://crrev.com/34ddcd79de5893b5fb9a2927f8087a0e80aee2b8/drivers/net/wireless/iwl7000/iwlwifi/mvm/utils.c [modify] https://crrev.com/34ddcd79de5893b5fb9a2927f8087a0e80aee2b8/drivers/net/wireless/iwl7000/iwlwifi/iwl-trans.h [modify] https://crrev.com/34ddcd79de5893b5fb9a2927f8087a0e80aee2b8/drivers/net/wireless/iwl7000/iwlwifi/mvm/sta.c [modify] https://crrev.com/34ddcd79de5893b5fb9a2927f8087a0e80aee2b8/drivers/net/wireless/iwl7000/iwlwifi/mvm/mvm.h
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2fa17b5c810f57f3c3c4bc01e64531798f431407 commit 2fa17b5c810f57f3c3c4bc01e64531798f431407 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Thu May 25 20:36:26 2017 CHROMIUM: iwl7000: mvm: don't mark TIDs that are not idle wrt BA as inactive A TID may not have traffic but still have a BA agreement active (or being setup / torn down) since a BA agreement can be triggered by a debugfs hook. Just avoid to consider such a TID as inactive to make the logic safer. BUG= chromium:719261 TEST=None Change-Id: I22852dbdac6364f2f663dedc875300deb7fc4b41 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> iwl7000-tree: 954b55992f4590afd5dd4410eaebf53e77f6d449 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/497989 Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit f232ba01e8c736d53dc84d5f519644e802bd3286) Reviewed-on: https://chromium-review.googlesource.com/516163 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/2fa17b5c810f57f3c3c4bc01e64531798f431407/drivers/net/wireless/iwl7000/iwlwifi/mvm/utils.c
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9afb2aff29be8989bee1b14dbc7765458a972406 commit 9afb2aff29be8989bee1b14dbc7765458a972406 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Thu May 25 23:00:20 2017 CHROMIUM: iwl7000: add a W/A for a scheduler hardware bug In case we need to move the scheduler write pointer by steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck. This leads to hardware error interrupts with status: 0x5A5A5A5A or alike. In order to work around this, detect in the transport layer that we are going to hit this case and tell iwlmvm to increment the sequence number of the packets. This allows to keep the requirement that the WiFi sequence number is in sync with the index in the scheduler Tx queue and it also allows to avoid the problematic sequence. This means that from time to time, we will start a queue from ssn + 1, but that shouldn't be a problem since we don't switch to new queues for AMPDU now that we have DQA which allows to keep the same queue while toggling the AMPDU state. This bug has been fixed on 9000 devices and up. BUG= chromium:719261 TEST=None Change-Id: Ide65c3f711ee62f17edde580fdca695f3acbf892 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> iwl7000-tree: 62d56763927c04755ee6a900b8859bd56a1c5484 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/498326 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 837fd39b8fa103f6d93849eb0a7fd7f36cae7d12) Reviewed-on: https://chromium-review.googlesource.com/516504 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/9afb2aff29be8989bee1b14dbc7765458a972406/drivers/net/wireless/iwl7000/iwlwifi/pcie/tx.c [modify] https://crrev.com/9afb2aff29be8989bee1b14dbc7765458a972406/drivers/net/wireless/iwl7000/iwlwifi/pcie/internal.h [modify] https://crrev.com/9afb2aff29be8989bee1b14dbc7765458a972406/drivers/net/wireless/iwl7000/iwlwifi/mvm/utils.c [modify] https://crrev.com/9afb2aff29be8989bee1b14dbc7765458a972406/drivers/net/wireless/iwl7000/iwlwifi/iwl-trans.h [modify] https://crrev.com/9afb2aff29be8989bee1b14dbc7765458a972406/drivers/net/wireless/iwl7000/iwlwifi/mvm/sta.c [modify] https://crrev.com/9afb2aff29be8989bee1b14dbc7765458a972406/drivers/net/wireless/iwl7000/iwlwifi/mvm/mvm.h
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/40526b98431d3208fede4cc9aea1bfb5e6915519 commit 40526b98431d3208fede4cc9aea1bfb5e6915519 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Thu May 25 23:00:24 2017 CHROMIUM: iwl7000: mvm: don't mark TIDs that are not idle wrt BA as inactive A TID may not have traffic but still have a BA agreement active (or being setup / torn down) since a BA agreement can be triggered by a debugfs hook. Just avoid to consider such a TID as inactive to make the logic safer. BUG= chromium:719261 TEST=None Change-Id: I22852dbdac6364f2f663dedc875300deb7fc4b41 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> iwl7000-tree: 954b55992f4590afd5dd4410eaebf53e77f6d449 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/498347 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 42542827b6611546545975f36120376cee24ae45) Reviewed-on: https://chromium-review.googlesource.com/516505 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/40526b98431d3208fede4cc9aea1bfb5e6915519/drivers/net/wireless/iwl7000/iwlwifi/mvm/utils.c
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e952cde10c440db4186ee97b1dae28fcbe5cc219 commit e952cde10c440db4186ee97b1dae28fcbe5cc219 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Thu May 25 23:00:27 2017 CHROMIUM: iwl7000: mvm: fix the recovery flow while connecting In BSS mode in the disconnection flow, mac80211 removes the AP station before the vif is set to unassociated. Our firmware wants it the other way around: first set the vif as unassociated, and then remove the AP station. In order to bridge between those two different behaviors, iwlmvm doesn't remove the station from the firmware when mac80211 removes it, but only after the vif is set to unassociated. The implementation is in iwl_mvm_bss_info_changed_station: if (assoc state was modified && mvmvif->ap_sta_id is VALID && assoc state is now UNASSC) remove_the_station_from_the_firmware() During the recovery flow, mac80211 re-adds the AP station and then reconfigures the vif. Since the vif is not associated, and then, we enter the if above (which was intended to be taken in the disconnection flow only) and remove the station we just added. This defeats the recovery flow. Fix this by not removing the AP station in this flow if we are in recovery flow. BUG=b:37920902, chromium:719261 TEST=Run continuous connect/disconnect cycles Change-Id: Iaec4545022c964aaeb49619901d6cb6d45e9988e Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: 1d392aeb9aa42a8792cce52db7ef8867105f1c3b Reviewed-on: https://chromium-review.googlesource.com/497688 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 5183cbfff75dcadc2176a1e1412eceb318ff0865) Reviewed-on: https://chromium-review.googlesource.com/516742 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/e952cde10c440db4186ee97b1dae28fcbe5cc219/drivers/net/wireless/iwl7000/iwlwifi/mvm/mac80211.c
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b4a7ccc5791b10c022ca14de95430daaf28e3965 commit b4a7ccc5791b10c022ca14de95430daaf28e3965 Author: Liad Kaufman <liad.kaufman@intel.com> Date: Thu May 25 23:03:50 2017 CHROMIUM: iwl7000: mvm: fix fw monitor 7000 HW recollecting To stop and start the FW monitor in the 7000 HW family we need to use a different bit, otherwise after stopping it for the first time - it won't get restarted. Use the correct bitmask. Note: This fix is only for DRAM collection mode. For other modes, an additional fix will be needed. BUG= chromium:719261 TEST=None Change-Id: Ie2176d0310bb41b604446f02f313c560574430a9 Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> iwl7000-tree: 9e5eb21aa386b3364d2afc3747ad1635e55dd7a9 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/498027 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 253ffe50feec0732e00564bc70a2037673814bb0) Reviewed-on: https://chromium-review.googlesource.com/516743 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/b4a7ccc5791b10c022ca14de95430daaf28e3965/drivers/net/wireless/iwl7000/iwlwifi/mvm/ops.c
,
May 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0c87e6c43efa02921a38bac6e493228deded1ed7 commit 0c87e6c43efa02921a38bac6e493228deded1ed7 Author: Luca Coelho <luciano.coelho@intel.com> Date: Thu May 25 23:03:58 2017 CHROMIUM: iwl7000: mvm: reset the HW before dumping if HW error is detected If the hardware is stuck, we can't read any of the memory we need to dump it, so we end up printing only 0xa5a5a5a5, which is useless. To solve this, poke the hardware by triggering a reset and re-enabling the clocks if we detect a HW error. Additionally, for this to work, remove unnecessary bh protection when calling the dump functions, so we can sleep to wait for the register writes. This is a combination of two patches from the iwl7000-tree. BUG=b:37920902, chromium:719261 TEST=Run continuous connect/disconnect cycles Change-Id: If7eec4a60eee806ac63198832193c116b22697ba Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: 054fad500f7398f18ea447778bc38f5361fedc5a iwl7000-tree: 47e688654d273b8d7ba5ee963ba9a8a3674952de Reviewed-on: https://chromium-review.googlesource.com/497987 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit cfce83f31475fcbfd37a197aad5095ac11826009) Reviewed-on: https://chromium-review.googlesource.com/516744 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/0c87e6c43efa02921a38bac6e493228deded1ed7/drivers/net/wireless/iwl7000/iwlwifi/pcie/rx.c [modify] https://crrev.com/0c87e6c43efa02921a38bac6e493228deded1ed7/drivers/net/wireless/iwl7000/iwlwifi/mvm/utils.c
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b3636287f76d196aea3b8f60e6df6982a01631fc commit b3636287f76d196aea3b8f60e6df6982a01631fc Author: Luca Coelho <luciano.coelho@intel.com> Date: Fri May 26 03:50:02 2017 CHROMIUM: iwl7000: mvm: reset the HW before dumping if HW error is detected If the hardware is stuck, we can't read any of the memory we need to dump it, so we end up printing only 0xa5a5a5a5, which is useless. To solve this, poke the hardware by triggering a reset and re-enabling the clocks if we detect a HW error. Additionally, for this to work, remove unnecessary bh protection when calling the dump functions, so we can sleep to wait for the register writes. This is a combination of two patches from the iwl7000-tree. BUG=b:37920902, chromium:719261 TEST=Run continuous connect/disconnect cycles Change-Id: If7eec4a60eee806ac63198832193c116b22697ba Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: 054fad500f7398f18ea447778bc38f5361fedc5a iwl7000-tree: 47e688654d273b8d7ba5ee963ba9a8a3674952de Reviewed-on: https://chromium-review.googlesource.com/497770 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 6fdcd69583a540ddb91daf494b44284c9402dac7) Reviewed-on: https://chromium-review.googlesource.com/516428 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/b3636287f76d196aea3b8f60e6df6982a01631fc/drivers/net/wireless-3.8/iwl7000/iwlwifi/pcie/rx.c [modify] https://crrev.com/b3636287f76d196aea3b8f60e6df6982a01631fc/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/utils.c
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/191c305a5091cfb75821534cd0f12b07df877ac2 commit 191c305a5091cfb75821534cd0f12b07df877ac2 Author: Liad Kaufman <liad.kaufman@intel.com> Date: Fri May 26 03:50:16 2017 CHROMIUM: iwl7000: mvm: fix fw monitor 7000 HW recollecting To stop and start the FW monitor in the 7000 HW family we need to use a different bit, otherwise after stopping it for the first time - it won't get restarted. Use the correct bitmask. Note: This fix is only for DRAM collection mode. For other modes, an additional fix will be needed. BUG= chromium:719261 TEST=None Change-Id: Ie2176d0310bb41b604446f02f313c560574430a9 Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> iwl7000-tree: 9e5eb21aa386b3364d2afc3747ad1635e55dd7a9 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/497769 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit f94af0fb6ddbbfcb405193ed1bad631e26b751db) Reviewed-on: https://chromium-review.googlesource.com/516430 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/191c305a5091cfb75821534cd0f12b07df877ac2/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/ops.c
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/20651b8797a672e689de5c65ebd7ff5be37142d5 commit 20651b8797a672e689de5c65ebd7ff5be37142d5 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri May 26 03:50:27 2017 CHROMIUM: iwl7000: mvm: don't mark TIDs that are not idle wrt BA as inactive A TID may not have traffic but still have a BA agreement active (or being setup / torn down) since a BA agreement can be triggered by a debugfs hook. Just avoid to consider such a TID as inactive to make the logic safer. BUG= chromium:719261 TEST=None Change-Id: I22852dbdac6364f2f663dedc875300deb7fc4b41 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> iwl7000-tree: 954b55992f4590afd5dd4410eaebf53e77f6d449 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/498249 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit ae2d46b3de2303094e59c3ae032d5d37d5da4486) Reviewed-on: https://chromium-review.googlesource.com/516431 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/20651b8797a672e689de5c65ebd7ff5be37142d5/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/utils.c
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/eb02f14bf27f22567e17175e05e21073cf2a1641 commit eb02f14bf27f22567e17175e05e21073cf2a1641 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri May 26 03:50:30 2017 CHROMIUM: iwl7000: add a W/A for a scheduler hardware bug In case we need to move the scheduler write pointer by steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck. This leads to hardware error interrupts with status: 0x5A5A5A5A or alike. In order to work around this, detect in the transport layer that we are going to hit this case and tell iwlmvm to increment the sequence number of the packets. This allows to keep the requirement that the WiFi sequence number is in sync with the index in the scheduler Tx queue and it also allows to avoid the problematic sequence. This means that from time to time, we will start a queue from ssn + 1, but that shouldn't be a problem since we don't switch to new queues for AMPDU now that we have DQA which allows to keep the same queue while toggling the AMPDU state. This bug has been fixed on 9000 devices and up. BUG= chromium:719261 TEST=None Change-Id: Ide65c3f711ee62f17edde580fdca695f3acbf892 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> iwl7000-tree: 62d56763927c04755ee6a900b8859bd56a1c5484 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/498248 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 4848f0101bd1d68f7386a2ff899555aa80805bcd) Reviewed-on: https://chromium-review.googlesource.com/516432 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/eb02f14bf27f22567e17175e05e21073cf2a1641/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/mvm.h [modify] https://crrev.com/eb02f14bf27f22567e17175e05e21073cf2a1641/drivers/net/wireless-3.8/iwl7000/iwlwifi/pcie/internal.h [modify] https://crrev.com/eb02f14bf27f22567e17175e05e21073cf2a1641/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/utils.c [modify] https://crrev.com/eb02f14bf27f22567e17175e05e21073cf2a1641/drivers/net/wireless-3.8/iwl7000/iwlwifi/pcie/tx.c [modify] https://crrev.com/eb02f14bf27f22567e17175e05e21073cf2a1641/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/sta.c [modify] https://crrev.com/eb02f14bf27f22567e17175e05e21073cf2a1641/drivers/net/wireless-3.8/iwl7000/iwlwifi/iwl-trans.h
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f43c2286a058ae0040c9b4723b4b2fc2bd164fcf commit f43c2286a058ae0040c9b4723b4b2fc2bd164fcf Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri May 26 04:15:47 2017 CHROMIUM: iwl7000: add a W/A for a scheduler hardware bug In case we need to move the scheduler write pointer by steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck. This leads to hardware error interrupts with status: 0x5A5A5A5A or alike. In order to work around this, detect in the transport layer that we are going to hit this case and tell iwlmvm to increment the sequence number of the packets. This allows to keep the requirement that the WiFi sequence number is in sync with the index in the scheduler Tx queue and it also allows to avoid the problematic sequence. This means that from time to time, we will start a queue from ssn + 1, but that shouldn't be a problem since we don't switch to new queues for AMPDU now that we have DQA which allows to keep the same queue while toggling the AMPDU state. This bug has been fixed on 9000 devices and up. BUG= chromium:719261 TEST=None Change-Id: Ide65c3f711ee62f17edde580fdca695f3acbf892 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> iwl7000-tree: 62d56763927c04755ee6a900b8859bd56a1c5484 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/497430 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 0e49cc0528cd19ea072f1538cbb0a0c88b9d34f5) Reviewed-on: https://chromium-review.googlesource.com/516514 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/f43c2286a058ae0040c9b4723b4b2fc2bd164fcf/drivers/net/wireless/iwl7000/iwlwifi/pcie/tx.c [modify] https://crrev.com/f43c2286a058ae0040c9b4723b4b2fc2bd164fcf/drivers/net/wireless/iwl7000/iwlwifi/pcie/internal.h [modify] https://crrev.com/f43c2286a058ae0040c9b4723b4b2fc2bd164fcf/drivers/net/wireless/iwl7000/iwlwifi/mvm/utils.c [modify] https://crrev.com/f43c2286a058ae0040c9b4723b4b2fc2bd164fcf/drivers/net/wireless/iwl7000/iwlwifi/iwl-trans.h [modify] https://crrev.com/f43c2286a058ae0040c9b4723b4b2fc2bd164fcf/drivers/net/wireless/iwl7000/iwlwifi/mvm/sta.c [modify] https://crrev.com/f43c2286a058ae0040c9b4723b4b2fc2bd164fcf/drivers/net/wireless/iwl7000/iwlwifi/mvm/mvm.h
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5ef1543dded7f9d5e3cdf1b64d93ffbef6782a69 commit 5ef1543dded7f9d5e3cdf1b64d93ffbef6782a69 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri May 26 04:15:43 2017 CHROMIUM: iwl7000: mvm: don't mark TIDs that are not idle wrt BA as inactive A TID may not have traffic but still have a BA agreement active (or being setup / torn down) since a BA agreement can be triggered by a debugfs hook. Just avoid to consider such a TID as inactive to make the logic safer. BUG= chromium:719261 TEST=None Change-Id: I22852dbdac6364f2f663dedc875300deb7fc4b41 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> iwl7000-tree: 954b55992f4590afd5dd4410eaebf53e77f6d449 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/497431 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 2f322e358fa80152d5240b01297ac14fe9177e88) Reviewed-on: https://chromium-review.googlesource.com/516513 Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/5ef1543dded7f9d5e3cdf1b64d93ffbef6782a69/drivers/net/wireless/iwl7000/iwlwifi/mvm/utils.c
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3b19b42d0fbc64e93231ed9a5ef970527ce2abe1 commit 3b19b42d0fbc64e93231ed9a5ef970527ce2abe1 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri May 26 05:51:02 2017 CHROMIUM: iwl7000: mvm: fix the recovery flow while connecting In BSS mode in the disconnection flow, mac80211 removes the AP station before the vif is set to unassociated. Our firmware wants it the other way around: first set the vif as unassociated, and then remove the AP station. In order to bridge between those two different behaviors, iwlmvm doesn't remove the station from the firmware when mac80211 removes it, but only after the vif is set to unassociated. The implementation is in iwl_mvm_bss_info_changed_station: if (assoc state was modified && mvmvif->ap_sta_id is VALID && assoc state is now UNASSC) remove_the_station_from_the_firmware() During the recovery flow, mac80211 re-adds the AP station and then reconfigures the vif. Since the vif is not associated, and then, we enter the if above (which was intended to be taken in the disconnection flow only) and remove the station we just added. This defeats the recovery flow. Fix this by not removing the AP station in this flow if we are in recovery flow. BUG=b:37920902, chromium:719261 TEST=Run continuous connect/disconnect cycles Change-Id: Iaec4545022c964aaeb49619901d6cb6d45e9988e Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> iwl7000-tree: 1d392aeb9aa42a8792cce52db7ef8867105f1c3b Reviewed-on: https://chromium-review.googlesource.com/497316 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 1c86c2d04201642d716233853d452429660ff8ec) Reviewed-on: https://chromium-review.googlesource.com/516829 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/3b19b42d0fbc64e93231ed9a5ef970527ce2abe1/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/mac80211.c
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/da3356074af974b1fd7eb105099a56e5b53b526f commit da3356074af974b1fd7eb105099a56e5b53b526f Author: Liad Kaufman <liad.kaufman@intel.com> Date: Fri May 26 05:51:05 2017 CHROMIUM: iwl7000: mvm: fix fw monitor 7000 HW recollecting To stop and start the FW monitor in the 7000 HW family we need to use a different bit, otherwise after stopping it for the first time - it won't get restarted. Use the correct bitmask. Note: This fix is only for DRAM collection mode. For other modes, an additional fix will be needed. BUG= chromium:719261 TEST=None Change-Id: Ie2176d0310bb41b604446f02f313c560574430a9 Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> iwl7000-tree: 9e5eb21aa386b3364d2afc3747ad1635e55dd7a9 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/497314 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit b07140ca379c9a6cae46d7e6e1c9f03fa4cba6bc) Reviewed-on: https://chromium-review.googlesource.com/516830 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/da3356074af974b1fd7eb105099a56e5b53b526f/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/ops.c
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/da3356074af974b1fd7eb105099a56e5b53b526f commit da3356074af974b1fd7eb105099a56e5b53b526f Author: Liad Kaufman <liad.kaufman@intel.com> Date: Fri May 26 05:51:05 2017 CHROMIUM: iwl7000: mvm: fix fw monitor 7000 HW recollecting To stop and start the FW monitor in the 7000 HW family we need to use a different bit, otherwise after stopping it for the first time - it won't get restarted. Use the correct bitmask. Note: This fix is only for DRAM collection mode. For other modes, an additional fix will be needed. BUG= chromium:719261 TEST=None Change-Id: Ie2176d0310bb41b604446f02f313c560574430a9 Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> iwl7000-tree: 9e5eb21aa386b3364d2afc3747ad1635e55dd7a9 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/497314 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit b07140ca379c9a6cae46d7e6e1c9f03fa4cba6bc) Reviewed-on: https://chromium-review.googlesource.com/516830 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/da3356074af974b1fd7eb105099a56e5b53b526f/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/ops.c
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ed4909a3b40e156c50658b0f772bb8bd44376149 commit ed4909a3b40e156c50658b0f772bb8bd44376149 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri May 26 05:53:16 2017 CHROMIUM: iwl7000: mvm: don't mark TIDs that are not idle wrt BA as inactive A TID may not have traffic but still have a BA agreement active (or being setup / torn down) since a BA agreement can be triggered by a debugfs hook. Just avoid to consider such a TID as inactive to make the logic safer. BUG= chromium:719261 TEST=None Change-Id: I22852dbdac6364f2f663dedc875300deb7fc4b41 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> iwl7000-tree: 954b55992f4590afd5dd4410eaebf53e77f6d449 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/498290 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 48b0f3a775f207f9f38bb1f376afc924d5aec370) Reviewed-on: https://chromium-review.googlesource.com/516831 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/ed4909a3b40e156c50658b0f772bb8bd44376149/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/utils.c
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4ce21c012c69413a29acf413e3e14b02305d9645 commit 4ce21c012c69413a29acf413e3e14b02305d9645 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Fri May 26 05:53:20 2017 CHROMIUM: iwl7000: add a W/A for a scheduler hardware bug In case we need to move the scheduler write pointer by steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck. This leads to hardware error interrupts with status: 0x5A5A5A5A or alike. In order to work around this, detect in the transport layer that we are going to hit this case and tell iwlmvm to increment the sequence number of the packets. This allows to keep the requirement that the WiFi sequence number is in sync with the index in the scheduler Tx queue and it also allows to avoid the problematic sequence. This means that from time to time, we will start a queue from ssn + 1, but that shouldn't be a problem since we don't switch to new queues for AMPDU now that we have DQA which allows to keep the same queue while toggling the AMPDU state. This bug has been fixed on 9000 devices and up. BUG= chromium:719261 TEST=None Change-Id: Ide65c3f711ee62f17edde580fdca695f3acbf892 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> iwl7000-tree: 62d56763927c04755ee6a900b8859bd56a1c5484 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-on: https://chromium-review.googlesource.com/498289 Commit-Ready: Kirtika Ruchandani <kirtika@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> (cherry picked from commit 1ab71e50619ed5662a4038d8928fea0071d77120) Reviewed-on: https://chromium-review.googlesource.com/516832 Trybot-Ready: Kirtika Ruchandani <kirtika@chromium.org> Commit-Queue: Kirtika Ruchandani <kirtika@chromium.org> Tested-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/4ce21c012c69413a29acf413e3e14b02305d9645/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/mvm.h [modify] https://crrev.com/4ce21c012c69413a29acf413e3e14b02305d9645/drivers/net/wireless-3.8/iwl7000/iwlwifi/pcie/internal.h [modify] https://crrev.com/4ce21c012c69413a29acf413e3e14b02305d9645/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/utils.c [modify] https://crrev.com/4ce21c012c69413a29acf413e3e14b02305d9645/drivers/net/wireless-3.8/iwl7000/iwlwifi/pcie/tx.c [modify] https://crrev.com/4ce21c012c69413a29acf413e3e14b02305d9645/drivers/net/wireless-3.8/iwl7000/iwlwifi/mvm/sta.c [modify] https://crrev.com/4ce21c012c69413a29acf413e3e14b02305d9645/drivers/net/wireless-3.8/iwl7000/iwlwifi/iwl-trans.h
,
Jan 3 2018
,
Mar 10 2018
,
Sep 13
Bulk verify old fixed bugs... |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by kirtika@chromium.org
, May 7 2017