pull request: iwlwifi-next 2014-1-20

pull request: iwlwifi-next 2014-1-20

[Emmanuel Grumbach]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

Hi John,

Well... I know... Not something to be proud of...

A critical bug has been reported on all NICs supported by iwldvm.
iwlwifi would simply panic upon interface up This patch fixes this. The
offending code is by me and is present in wireless-next.git and hence in
net-next.git.
I hope that this pull reuqest can reach 3.14-rc1 otherwise, all the
system with NICs supported by iwldvm will simply lock up.

Thanks!


The following changes since commit cf38e4f756d6396657c76f72ef42b6f47c523f97:

  iwlwifi: mvm: don't use highest rate in VHT MCS Set (2014-01-13
22:17:22 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git
for-john

for you to fetch changes up to 23e76d1a516eef416fb5c038791e943fc0916b67:

  iwlwifi: pcie: don't panic on host commands in iwldvm (2014-01-20
12:32:06 +0200)

----------------------------------------------------------------
Emmanuel Grumbach (1):
      iwlwifi: pcie: don't panic on host commands in iwldvm

 drivers/net/wireless/iwlwifi/pcie/tx.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] iwlwifi: pcie: don't panic on host commands in iwldvm

[Emmanuel Grumbach]

From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

None of the devices supported by iwldvm have support for
shadow registers. This means that we wake the NIC
when we increment the write pointer on Tx ring.
This happened even before my bad commit mentionned below.
Since my commit below, we wake up the NIC when we put a
host command on the ring regardless of shadow register
support. This means that in iwldvm (when the NIC doesn't
support shadow register), we wake up the NIC twice:

pcie_enqueue_hcmd:
	wake up the NIC
	iwl_pcie_txq_inc_wr_ptr:
		wake up the NIC - no shadow reg support

Since waking up the NIC means that we need to acquire a
spinlock, this obviously leads to a recursive spinlock
and hence a freeze.

Fixes: b9439491055a ("iwlwifi: pcie: keep the NIC awake when commands are in flight")
Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
 drivers/net/wireless/iwlwifi/pcie/tx.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c b/drivers/net/wireless/iwlwifi/pcie/tx.c
index 3b14fa8..3d54900 100644
--- a/drivers/net/wireless/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
@@ -289,13 +289,15 @@ static void iwl_pcie_txq_inval_byte_cnt_tbl(struct iwl_trans *trans,
  */
 void iwl_pcie_txq_inc_wr_ptr(struct iwl_trans *trans, struct iwl_txq *txq)
 {
+	struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
 	u32 reg = 0;
 	int txq_id = txq->q.id;
 
 	if (txq->need_update == 0)
 		return;
 
-	if (trans->cfg->base_params->shadow_reg_enable) {
+	if (trans->cfg->base_params->shadow_reg_enable ||
+	    txq_id == trans_pcie->cmd_queue) {
 		/* shadow register enabled */
 		iwl_write32(trans, HBUS_TARG_WRPTR,
 			    txq->q.write_ptr | (txq_id << 8));
-- 
1.7.9.5

Re: [PATCH] iwlwifi: pcie: don't panic on host commands in iwldvm

[Kalle Valo]

Emmanuel Grumbach <egrumbach@gmail.com> writes:

> From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>
> None of the devices supported by iwldvm have support for
> shadow registers. This means that we wake the NIC
> when we increment the write pointer on Tx ring.
> This happened even before my bad commit mentionned below.
> Since my commit below, we wake up the NIC when we put a
> host command on the ring regardless of shadow register
> support. This means that in iwldvm (when the NIC doesn't
> support shadow register), we wake up the NIC twice:
>
> pcie_enqueue_hcmd:
> 	wake up the NIC
> 	iwl_pcie_txq_inc_wr_ptr:
> 		wake up the NIC - no shadow reg support
>
> Since waking up the NIC means that we need to acquire a
> spinlock, this obviously leads to a recursive spinlock
> and hence a freeze.
>
> Fixes: b9439491055a ("iwlwifi: pcie: keep the NIC awake when commands are in flight")
> Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
> Reviewed-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Ah, this is why my laptop was hanging during boot with latest
wireless-testing? Thanks for fixing this. 

FWIW:

Tested-by: Kalle Valo <kvalo@adurom.com>

-- 
Kalle Valo

Re: pull request: iwlwifi-next 2014-1-20

[John W. Linville]

On Mon, Jan 20, 2014 at 12:46:31PM +0200, Emmanuel Grumbach wrote:
> Hi John,
> 
> Well... I know... Not something to be proud of...
> 
> A critical bug has been reported on all NICs supported by iwldvm.
> iwlwifi would simply panic upon interface up This patch fixes this. The
> offending code is by me and is present in wireless-next.git and hence in
> net-next.git.
> I hope that this pull reuqest can reach 3.14-rc1 otherwise, all the
> system with NICs supported by iwldvm will simply lock up.
> 
> Thanks!
> 
> 
> The following changes since commit cf38e4f756d6396657c76f72ef42b6f47c523f97:
> 
>   iwlwifi: mvm: don't use highest rate in VHT MCS Set (2014-01-13
> 22:17:22 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git
> for-john
> 
> for you to fetch changes up to 23e76d1a516eef416fb5c038791e943fc0916b67:
> 
>   iwlwifi: pcie: don't panic on host commands in iwldvm (2014-01-20
> 12:32:06 +0200)
> 
> ----------------------------------------------------------------
> Emmanuel Grumbach (1):
>       iwlwifi: pcie: don't panic on host commands in iwldvm
> 
>  drivers/net/wireless/iwlwifi/pcie/tx.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Pulling now...

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.