Fixing rt2500pci

Fixing rt2500pci

[Peter Chubb]

In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the
released 2.6.26, my RaLink rt2500 card wouldn't associate.

Git-bisect led me to this patch:

	61486e0f68d1f8966c09b734566a187d42d65c54
	rt2x00: Remove ieee80211_tx_control argument from write_tx_desc()

I believe that there are two problems with that patch.  Setting the Tx
Length has been removed inadvertently, and one of the conditions for
when to set ifs to IFS_SIFS has also been removed.

This patch fixes those things, and with it my card works again.

Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>

diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 1724ce9..4ba2165 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1198,6 +1198,7 @@ static void rt2500pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
 	rt2x00_set_field32(&word, TXD_W0_IFS, txdesc->ifs);
 	rt2x00_set_field32(&word, TXD_W0_RETRY_MODE,
 			   test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags));
+	rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skbdesc->data_len);
 	rt2x00_set_field32(&word, TXD_W0_CIPHER_ALG, CIPHER_NONE);
 	rt2x00_desc_write(txd, 0, word);
 }
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index e1368f7..a11d6ff 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -691,7 +691,8 @@ void rt2x00lib_write_tx_desc(struct rt2x00_dev *rt2x00dev,
 	 * Set ifs to IFS_SIFS when the this is not the first fragment,
 	 * or this fragment came after RTS/CTS.
 	 */
-	if (test_bit(ENTRY_TXD_RTS_FRAME, &txdesc.flags)) {
+	if ((seq_ctrl & IEEE80211_SCTL_FRAG)  ||
+		test_bit(ENTRY_TXD_RTS_FRAME, &txdesc.flags)) {
 		txdesc.ifs = IFS_SIFS;
 	} else if (control->flags & IEEE80211_TXCTL_FIRST_FRAGMENT) {
 		__set_bit(ENTRY_TXD_FIRST_FRAGMENT, &txdesc.flags);

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

Re: Fixing rt2500pci

[Ivo van Doorn]

On Wednesday 30 July 2008, Peter Chubb wrote:
> 
> In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the
> released 2.6.26, my RaLink rt2500 card wouldn't associate.
> 
> Git-bisect led me to this patch:
> 
> 	61486e0f68d1f8966c09b734566a187d42d65c54
> 	rt2x00: Remove ieee80211_tx_control argument from write_tx_desc()
> 
> I believe that there are two problems with that patch.  Setting the Tx
> Length has been removed inadvertently, and one of the conditions for
> when to set ifs to IFS_SIFS has also been removed.
> 
> This patch fixes those things, and with it my card works again.
> 
> Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
> 
> diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
> index 1724ce9..4ba2165 100644
> --- a/drivers/net/wireless/rt2x00/rt2500pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2500pci.c
> @@ -1198,6 +1198,7 @@ static void rt2500pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
>  	rt2x00_set_field32(&word, TXD_W0_IFS, txdesc->ifs);
>  	rt2x00_set_field32(&word, TXD_W0_RETRY_MODE,
>  			   test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags));
> +	rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skbdesc->data_len);
>  	rt2x00_set_field32(&word, TXD_W0_CIPHER_ALG, CIPHER_NONE);
>  	rt2x00_desc_write(txd, 0, word);
>  }

How could that have disappeared? good catch.
The above change is:

Acked-by: Ivo van Doorn <IvDoorn@gmail.com>

But:

> diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
> index e1368f7..a11d6ff 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00dev.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
> @@ -691,7 +691,8 @@ void rt2x00lib_write_tx_desc(struct rt2x00_dev *rt2x00dev,
>  	 * Set ifs to IFS_SIFS when the this is not the first fragment,
>  	 * or this fragment came after RTS/CTS.
>  	 */
> -	if (test_bit(ENTRY_TXD_RTS_FRAME, &txdesc.flags)) {
> +	if ((seq_ctrl & IEEE80211_SCTL_FRAG)  ||
> +		test_bit(ENTRY_TXD_RTS_FRAME, &txdesc.flags)) {
>  		txdesc.ifs = IFS_SIFS;
>  	} else if (control->flags & IEEE80211_TXCTL_FIRST_FRAGMENT) {
>  		__set_bit(ENTRY_TXD_FIRST_FRAGMENT, &txdesc.flags);

The above does not correspond with legacy driver, so I am hesitant in accepting this change.
Unless you are _absolutely_ sure this change does fix the issue, and the databate count
initialization is not sufficient on its own. If that is not the case, please resend the patch with the
rt2x00dev.c change ommitted and my ack added. (Please add John Linville to the CC list as well,
so it can be merged faster :) )

Ivo

Re: Fixing rt2500pci

[Ivo van Doorn]

On Wednesday 30 July 2008, Ivo van Doorn wrote:
> On Wednesday 30 July 2008, Peter Chubb wrote:
> > 
> > In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the
> > released 2.6.26, my RaLink rt2500 card wouldn't associate.
> > 
> > Git-bisect led me to this patch:
> > 
> > 	61486e0f68d1f8966c09b734566a187d42d65c54
> > 	rt2x00: Remove ieee80211_tx_control argument from write_tx_desc()
> > 
> > I believe that there are two problems with that patch.  Setting the Tx
> > Length has been removed inadvertently, and one of the conditions for
> > when to set ifs to IFS_SIFS has also been removed.
> > 
> > This patch fixes those things, and with it my card works again.
> > 
> > Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
> > 
> > diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
> > index 1724ce9..4ba2165 100644
> > --- a/drivers/net/wireless/rt2x00/rt2500pci.c
> > +++ b/drivers/net/wireless/rt2x00/rt2500pci.c
> > @@ -1198,6 +1198,7 @@ static void rt2500pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
> >  	rt2x00_set_field32(&word, TXD_W0_IFS, txdesc->ifs);
> >  	rt2x00_set_field32(&word, TXD_W0_RETRY_MODE,
> >  			   test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags));
> > +	rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skbdesc->data_len);
> >  	rt2x00_set_field32(&word, TXD_W0_CIPHER_ALG, CIPHER_NONE);
> >  	rt2x00_desc_write(txd, 0, word);
> >  }
> 
> How could that have disappeared? good catch.
> The above change is:
> 
> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> 
> But:
> 
> > diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
> > index e1368f7..a11d6ff 100644
> > --- a/drivers/net/wireless/rt2x00/rt2x00dev.c
> > +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
> > @@ -691,7 +691,8 @@ void rt2x00lib_write_tx_desc(struct rt2x00_dev *rt2x00dev,
> >  	 * Set ifs to IFS_SIFS when the this is not the first fragment,
> >  	 * or this fragment came after RTS/CTS.
> >  	 */
> > -	if (test_bit(ENTRY_TXD_RTS_FRAME, &txdesc.flags)) {
> > +	if ((seq_ctrl & IEEE80211_SCTL_FRAG)  ||
> > +		test_bit(ENTRY_TXD_RTS_FRAME, &txdesc.flags)) {
> >  		txdesc.ifs = IFS_SIFS;
> >  	} else if (control->flags & IEEE80211_TXCTL_FIRST_FRAGMENT) {
> >  		__set_bit(ENTRY_TXD_FIRST_FRAGMENT, &txdesc.flags);
> 
> The above does not correspond with legacy driver, so I am hesitant in accepting this change.
> Unless you are _absolutely_ sure this change does fix the issue, and the databate count
> initialization is not sufficient on its own. If that is not the case, please resend the patch with the
> rt2x00dev.c change ommitted and my ack added. (Please add John Linville to the CC list as well,
> so it can be merged faster :) )

Correction, the code does correspond with the legacy driver, but the codechange in:
61486e0f68d1f8966c09b734566a187d42d65c54 was correct since it still applies IFS_SIFS to
frames with fragments (excluding the first fragment).

So please resend the patch with only the rt2500pci change.

Ivo

Re: Fixing rt2500pci [PATCH]

[Peter Chubb]

In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the
released 2.6.26, my RaLink rt2500 card wouldn't associate.

Git-bisect led me to this patch:

	61486e0f68d1f8966c09b734566a187d42d65c54
	rt2x00: Remove ieee80211_tx_control argument from write_tx_desc()

I believe that there is a problem with that patch --- it
(inadvertantly) removes an extra line of code, that used to set the
DATABYTE_COUNT field.
 
This patch reinstates that line, and with it my card works again.
 
Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>

diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 1724ce9..4ba2165 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1198,6 +1198,7 @@ static void rt2500pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
 	rt2x00_set_field32(&word, TXD_W0_IFS, txdesc->ifs);
 	rt2x00_set_field32(&word, TXD_W0_RETRY_MODE,
 			   test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags));
+	rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skbdesc->data_len);
 	rt2x00_set_field32(&word, TXD_W0_CIPHER_ALG, CIPHER_NONE);
 	rt2x00_desc_write(txd, 0, word);
 }

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

Re: Fixing rt2500pci [PATCH]

[Peter Chubb]

In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the
released 2.6.26, my RaLink rt2500 card wouldn't associate.

Git-bisect led me to this patch:

	61486e0f68d1f8966c09b734566a187d42d65c54
	rt2x00: Remove ieee80211_tx_control argument from write_tx_desc()

I believe that there is a problem with that patch --- it
(inadvertantly) removes an extra line of code, that used to set the
DATABYTE_COUNT field.
 
This patch reinstates that line, and with it my card works again.

The original version I sent still used the skbdesc->data_len which has
been removed; this version of the patch applies on top of 2.6.27-rc1.
 
Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>


Index: linux-2.6-git/drivers/net/wireless/rt2x00/rt2500pci.c
===================================================================
--- linux-2.6-git.orig/drivers/net/wireless/rt2x00/rt2500pci.c	2008-07-31 10:58:43.000000000 +1000
+++ linux-2.6-git/drivers/net/wireless/rt2x00/rt2500pci.c	2008-07-31 11:40:44.000000000 +1000
@@ -1213,20 +1213,21 @@ static void rt2500pci_write_tx_desc(stru
 	rt2x00_set_field32(&word, TXD_W0_ACK,
 			   test_bit(ENTRY_TXD_ACK, &txdesc->flags));
 	rt2x00_set_field32(&word, TXD_W0_TIMESTAMP,
 			   test_bit(ENTRY_TXD_REQ_TIMESTAMP, &txdesc->flags));
 	rt2x00_set_field32(&word, TXD_W0_OFDM,
 			   test_bit(ENTRY_TXD_OFDM_RATE, &txdesc->flags));
 	rt2x00_set_field32(&word, TXD_W0_CIPHER_OWNER, 1);
 	rt2x00_set_field32(&word, TXD_W0_IFS, txdesc->ifs);
 	rt2x00_set_field32(&word, TXD_W0_RETRY_MODE,
 			   test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags));
+	rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skb->len);
 	rt2x00_set_field32(&word, TXD_W0_CIPHER_ALG, CIPHER_NONE);
 	rt2x00_desc_write(txd, 0, word);
 }
 
 /*
  * TX data initialization
  */
 static void rt2500pci_write_beacon(struct queue_entry *entry)
 {
 	struct rt2x00_dev *rt2x00dev = entry->queue->rt2x00dev;

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

Re: Fixing rt2500pci [PATCH]

[John Daiker]

Peter Chubb wrote:
> In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the
> released 2.6.26, my RaLink rt2500 card wouldn't associate.
>
> Git-bisect led me to this patch:
>
> 	61486e0f68d1f8966c09b734566a187d42d65c54
> 	rt2x00: Remove ieee80211_tx_control argument from write_tx_desc()
>
> I believe that there is a problem with that patch --- it
> (inadvertantly) removes an extra line of code, that used to set the
> DATABYTE_COUNT field.
>  
> This patch reinstates that line, and with it my card works again.
>
> The original version I sent still used the skbdesc->data_len which has
> been removed; this version of the patch applies on top of 2.6.27-rc1.
>  
> Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
>
>
> Index: linux-2.6-git/drivers/net/wireless/rt2x00/rt2500pci.c
> ===================================================================
> --- linux-2.6-git.orig/drivers/net/wireless/rt2x00/rt2500pci.c	2008-07-31 10:58:43.000000000 +1000
> +++ linux-2.6-git/drivers/net/wireless/rt2x00/rt2500pci.c	2008-07-31 11:40:44.000000000 +1000
> @@ -1213,20 +1213,21 @@ static void rt2500pci_write_tx_desc(stru
>  	rt2x00_set_field32(&word, TXD_W0_ACK,
>  			   test_bit(ENTRY_TXD_ACK, &txdesc->flags));
>  	rt2x00_set_field32(&word, TXD_W0_TIMESTAMP,
>  			   test_bit(ENTRY_TXD_REQ_TIMESTAMP, &txdesc->flags));
>  	rt2x00_set_field32(&word, TXD_W0_OFDM,
>  			   test_bit(ENTRY_TXD_OFDM_RATE, &txdesc->flags));
>  	rt2x00_set_field32(&word, TXD_W0_CIPHER_OWNER, 1);
>  	rt2x00_set_field32(&word, TXD_W0_IFS, txdesc->ifs);
>  	rt2x00_set_field32(&word, TXD_W0_RETRY_MODE,
>  			   test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags));
> +	rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skb->len);
>  	rt2x00_set_field32(&word, TXD_W0_CIPHER_ALG, CIPHER_NONE);
>  	rt2x00_desc_write(txd, 0, word);
>  }
>  
>  /*
>   * TX data initialization
>   */
>  static void rt2500pci_write_beacon(struct queue_entry *entry)
>  {
>  	struct rt2x00_dev *rt2x00dev = entry->queue->rt2x00dev;
>
> --
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
> http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>   
I can confirm that this is working on top of 
2.6.27-rc1-94ad374a0751f40d25e22e036c37f7263569d24c

Acked-by: John Daiker <daikerjohn@gmail.com>

Re: Fixing rt2500pci [PATCH]

[Ivo van Doorn]

On Thursday 31 July 2008, Peter Chubb wrote:
> 
> In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the
> released 2.6.26, my RaLink rt2500 card wouldn't associate.
> 
> Git-bisect led me to this patch:
> 
> 	61486e0f68d1f8966c09b734566a187d42d65c54
> 	rt2x00: Remove ieee80211_tx_control argument from write_tx_desc()
> 
> I believe that there is a problem with that patch --- it
> (inadvertantly) removes an extra line of code, that used to set the
> DATABYTE_COUNT field.
>  
> This patch reinstates that line, and with it my card works again.
>  
> Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>

Thanks,

John, please push this patch upstream. This one is really important. :)

> diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
> index 1724ce9..4ba2165 100644
> --- a/drivers/net/wireless/rt2x00/rt2500pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2500pci.c
> @@ -1198,6 +1198,7 @@ static void rt2500pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
>  	rt2x00_set_field32(&word, TXD_W0_IFS, txdesc->ifs);
>  	rt2x00_set_field32(&word, TXD_W0_RETRY_MODE,
>  			   test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags));
> +	rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skbdesc->data_len);
>  	rt2x00_set_field32(&word, TXD_W0_CIPHER_ALG, CIPHER_NONE);
>  	rt2x00_desc_write(txd, 0, word);
>  }
> 
> --
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
> http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
> --
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
> http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
> 

Re: Fixing rt2500pci [PATCH]

[Ivo van Doorn]

On Thursday 31 July 2008, Peter Chubb wrote:
> 
> In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the
> released 2.6.26, my RaLink rt2500 card wouldn't associate.
> 
> Git-bisect led me to this patch:
> 
> 	61486e0f68d1f8966c09b734566a187d42d65c54
> 	rt2x00: Remove ieee80211_tx_control argument from write_tx_desc()
> 
> I believe that there is a problem with that patch --- it
> (inadvertantly) removes an extra line of code, that used to set the
> DATABYTE_COUNT field.
>  
> This patch reinstates that line, and with it my card works again.
>  
> Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>

[stable@kernel.org added to CC]

The 2.6.27 version of the patch has already been pushed upstream,
this one is for 2.6.26-stable since this fixes a regression introduced after 2.6.25.

---
> diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
> index 1724ce9..4ba2165 100644
> --- a/drivers/net/wireless/rt2x00/rt2500pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2500pci.c
> @@ -1198,6 +1198,7 @@ static void rt2500pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
>  	rt2x00_set_field32(&word, TXD_W0_IFS, txdesc->ifs);
>  	rt2x00_set_field32(&word, TXD_W0_RETRY_MODE,
>  			   test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags));
> +	rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skbdesc->data_len);
>  	rt2x00_set_field32(&word, TXD_W0_CIPHER_ALG, CIPHER_NONE);
>  	rt2x00_desc_write(txd, 0, word);
>  }
> 
> --
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
> http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
> --
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
> http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
> 

Re: [stable] Fixing rt2500pci [PATCH]

[Greg KH]

On Tue, Aug 12, 2008 at 12:01:26PM +0200, Ivo van Doorn wrote:
> On Thursday 31 July 2008, Peter Chubb wrote:
> > 
> > In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the
> > released 2.6.26, my RaLink rt2500 card wouldn't associate.
> > 
> > Git-bisect led me to this patch:
> > 
> > 	61486e0f68d1f8966c09b734566a187d42d65c54
> > 	rt2x00: Remove ieee80211_tx_control argument from write_tx_desc()
> > 
> > I believe that there is a problem with that patch --- it
> > (inadvertantly) removes an extra line of code, that used to set the
> > DATABYTE_COUNT field.
> >  
> > This patch reinstates that line, and with it my card works again.
> >  
> > Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
> > Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> 
> [stable@kernel.org added to CC]
> 
> The 2.6.27 version of the patch has already been pushed upstream,
> this one is for 2.6.26-stable since this fixes a regression introduced after 2.6.25.

Are you sure?  Looking at 2.6.26, the code in that function looks like
it is properly setting the TXD_W0_DATABYTE_COUNT, field.

If it's really a problem, can you send stable@kernel.org a patch that
applies to 2.6.26.2?

thanks,

greg k-h

Re: [stable] Fixing rt2500pci [PATCH]

[Ivo van Doorn]

On Sunday 17 August 2008, Greg KH wrote:
> On Tue, Aug 12, 2008 at 12:01:26PM +0200, Ivo van Doorn wrote:
> > On Thursday 31 July 2008, Peter Chubb wrote:
> > > 
> > > In kernel version 2.6.26-rc9 my wireless LAN card worked; but in the
> > > released 2.6.26, my RaLink rt2500 card wouldn't associate.
> > > 
> > > Git-bisect led me to this patch:
> > > 
> > > 	61486e0f68d1f8966c09b734566a187d42d65c54
> > > 	rt2x00: Remove ieee80211_tx_control argument from write_tx_desc()
> > > 
> > > I believe that there is a problem with that patch --- it
> > > (inadvertantly) removes an extra line of code, that used to set the
> > > DATABYTE_COUNT field.
> > >  
> > > This patch reinstates that line, and with it my card works again.
> > >  
> > > Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
> > > Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> > 
> > [stable@kernel.org added to CC]
> > 
> > The 2.6.27 version of the patch has already been pushed upstream,
> > this one is for 2.6.26-stable since this fixes a regression introduced after 2.6.25.
> 
> Are you sure?  Looking at 2.6.26, the code in that function looks like
> it is properly setting the TXD_W0_DATABYTE_COUNT, field.
> 
> If it's really a problem, can you send stable@kernel.org a patch that
> applies to 2.6.26.2?

Hmm, that is weird, that line is indeed present, which means that the
commit which was responsible for the breakage wasn't in 2.6.26.
I guess peter tested a git checkout from after 2.6.26 or something. :S

Ivo

Re: Fixing rt2500pci

[Peter Chubb]

Ther appears to be another problem in here somewhere.  Every now and
then I get a general protect fault with this card and 2.6.27-rc1.
This is on an AMD64 box.  I'm not sure I entirely believe the stack
backtrace. 

general protection fault: 0000 [1] PREEMPT 
CPU 0 
Modules linked in: radeon rfcomm l2cap bluetooth tun sd_mod scsi_mod
pcmcia rt2500pci rt2x00pci rt2x00lib led_class rtc_cmos mac80211
rtc_core snd_hda_intel yenta_socket serio_raw usbhid i2c_piix4
firewire_ohci rtc_lib eeprom_93cx6 firewire_core snd_hwdep i2c_core
rsrc_nonstatic hid

Pid: 2188, comm: rt2500pci Not tainted 2.6.27-rc1 #48
RIP: 0010:[<ffffffff8025d42f>]  [<ffffffff8025d42f>] put_page+0x1/0xc9
RSP: 0000:ffff88003ef29c50  EFLAGS: 00010256
RAX: 0000000000000000 RBX: ffff88003e752c00 RCX: 0000000000000000
RDX: ffff8800363ca9c0 RSI: 0000000000000000 RDI: e9d21529d12041df
RBP: 0000000000000001 R08: ffff88003f2a02a0 R09: ffff88003ef29b50
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003eda9800
R13: ffff8800363ca014 R14: ffffffff8069fae0 R15: ffff88003eda9000
FS:  00007f94becea6f0(0000) GS:ffffffff8066de40(0000) knlGS:00000000f7b4b6c0
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00007f668d049000 CR3: 000000002c0ab000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rt2500pci (pid: 2188, threadinfo ffff88003ef28000, task ffff88003f9ae100)
Stack:  ffff88003e752c00 ffffffff8046ba68 ffff88003e752c00 ffff88003e752c00
 ffff88003fb68a40 ffffffff8046b929 ffff88003eda97d0 ffffffffa00a6851
 ffff88003f296700 ffff88003e752c00 0000000000000000 ffffffffa00aeba3
Call Trace:
 [<ffffffff8046ba68>] ? skb_release_data+0x65/0xac
 [<ffffffff8046b929>] ? __kfree_skb+0x9/0x6d
 [<ffffffffa00a6851>] ? ieee80211_sta_rx_queued_mgmt+0xc41/0xc67 [mac80211]
 [<ffffffffa00aeba3>] ? ieee80211_master_start_xmit+0x2dc/0x2f5 [mac80211]
 [<ffffffff8022514f>] ? set_next_entity+0x18/0x36
 [<ffffffff8047ede9>] ? __qdisc_run+0xd9/0x1e4
 [<ffffffff8047377a>] ? dev_queue_xmit+0x41f/0x45d
 [<ffffffffa00a1fbc>] ? ieee80211_rx_bss_get+0xb3/0xbf [mac80211]
 [<ffffffffa00a1fe9>] ? ieee80211_rx_bss_put+0x21/0xef [mac80211]
 [<ffffffff802250f3>] ? __dequeue_entity+0x25/0x69
 [<ffffffffa00a79f9>] ? ieee80211_sta_work+0x96/0x6e1 [mac80211]
 [<ffffffff802251fb>] ? pick_next_task_fair+0x71/0x83
 [<ffffffff8050d98e>] ? thread_return+0x30/0xa9
 [<ffffffffa00a7963>] ? ieee80211_sta_work+0x0/0x6e1 [mac80211]
 [<ffffffff80238582>] ? run_workqueue+0xb1/0x17a
 [<ffffffff80238eb4>] ? worker_thread+0xd0/0xdb
 [<ffffffff8023b92b>] ? autoremove_wake_function+0x0/0x2e
 [<ffffffff80238de4>] ? worker_thread+0x0/0xdb
 [<ffffffff8023b826>] ? kthread+0x47/0x75
 [<ffffffff80225a9f>] ? schedule_tail+0x18/0x51
 [<ffffffff8020bb09>] ? child_rip+0xa/0x11
 [<ffffffff8023b7df>] ? kthread+0x0/0x75
 [<ffffffff8020baff>] ? child_rip+0x0/0x11

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

Re: Fixing rt2500pci

[Peter Chubb]

>>>>> "Peter" == Peter Chubb <peterc@gelato.unsw.edu.au> writes:

Peter> Ther appears to be another problem in here somewhere.  Every
Peter> now and then I get a general protect fault with this card and
Peter> 2.6.27-rc1.  This is on an AMD64 box.  I'm not sure I entirely
Peter> believe the stack backtrace.

I recompiled with frame pointers.  Here's another trace.  i believe
this one :-) This is 2.6.27-rc1 as of 4/8/2008 with my patch applied

general protection fault: 0000 [1] PREEMPT 
CPU 0 
Modules linked in: radeon rfcomm l2cap bluetooth sd_mod scsi_mod pcmcia rt2500pci rt2x00pci rt2x00lib led_class mac80211 i2c_piix4 rtc_cmos firewire_ohci snd_hda_intel eeprom_93cx6 rtc_core yenta_socket firewire_core serio_raw usbhid rtc_lib rsrc_nonstatic i2c_core snd_hwdep hid
Pid: 2181, comm: rt2500pci Not tainted 2.6.27-rc1 #51
RIP: 0010:[<ffffffff80260c8d>]  [<ffffffff80260c8d>] put_page+0xc/0xd6
RSP: 0018:ffff88003fbd9bf0  EFLAGS: 00010286
RAX: 0000000000000000 RBX: fd94ea9eed2c0b41 RCX: 0000000000000000
RDX: ffff8800352b89c0 RSI: 0000000000000000 RDI: fd94ea9eed2c0b41
RBP: ffff88003fbd9c00 R08: ffff88003f32e2a0 R09: 0000000000000002
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
R13: ffff8800352b8014 R14: ffff88003cc0c000 R15: 0000000000000000
FS:  00007fb7bcdbe6f0(0000) GS:ffffffff8068ae40(0000) knlGS:00000000f7bcf6c0
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00000000006d20c8 CR3: 000000003527c000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rt2500pci (pid: 2181, threadinfo ffff88003fbd8000, task ffff88003fb00b00)
Stack:  0000000000000000 ffff880035283900 ffff88003fbd9c20 ffffffff80482ee8
 ffff880035283900 ffff88003cc60c00 ffff88003fbd9c40 ffffffff8048358a
 ffff88003cc60c00 ffff880035283900 ffff88003fbd9c60 ffffffff80482d85
Call Trace:
 [<ffffffff80482ee8>] skb_release_data+0x68/0xac
 [<ffffffff8048358a>] skb_release_all+0x6f/0x73
 [<ffffffff80482d85>] __kfree_skb+0x11/0x77
 [<ffffffff80482e11>] kfree_skb+0x26/0x28
 [<ffffffffa00a8ee4>] ieee80211_sta_rx_queued_mgmt+0xd5f/0xd85 [mac80211]
 [<ffffffff804835fa>] ? __alloc_skb+0x3b/0x12e
 [<ffffffff80496f9d>] ? __qdisc_run+0xd1/0x1ea
 [<ffffffff8048b197>] ? dev_queue_xmit+0x427/0x468
 [<ffffffff8036b433>] ? delay_tsc+0x25/0xa2
 [<ffffffff8036b3a5>] ? __delay+0xa/0xc
 [<ffffffff8036b3c9>] ? __const_udelay+0x22/0x24
 [<ffffffffa00cf11f>] ? rt2500pci_bbp_check+0x35/0x45 [rt2500pci]
 [<ffffffffa00aa066>] ieee80211_sta_work+0x99/0x6c3 [mac80211]
 [<ffffffff8052ae7e>] ? thread_return+0x30/0xa9
 [<ffffffffa00a9fcd>] ? ieee80211_sta_work+0x0/0x6c3 [mac80211]
 [<ffffffff8023a2b9>] run_workqueue+0xb2/0x178
 [<ffffffff8023ac9a>] worker_thread+0xd3/0xe0
 [<ffffffff8023d9b1>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023abc7>] ? worker_thread+0x0/0xe0
 [<ffffffff8023d8a1>] kthread+0x49/0x78
 [<ffffffff8020bc59>] child_rip+0xa/0x11
 [<ffffffff8023d858>] ? kthread+0x0/0x78
 [<ffffffff8020bc4f>] ? child_rip+0x0/0x11


Code: f6 80 38 e0 ff ff 08 74 05 e8 ea a2 2c 00 5e 5b c9 c3 55 48 89 e5 e8 71 ff ff ff c9 31 c0 c3 55 48 89 e5 53 48 89 fb 48 83 ec 08 <f7> 07 00 60 00 00 74 0a e8 05 f9 ff ff e9 b4 00 00 00 ff 4f 08 
RIP  [<ffffffff80260c8d>] put_page+0xc/0xd6
 RSP <ffff88003fbd9bf0>

Re: Fixing rt2500pci

[Ivo van Doorn]

On Tuesday 05 August 2008, Peter Chubb wrote:
> >>>>> "Peter" == Peter Chubb <peterc@gelato.unsw.edu.au> writes:
> 
> Peter> Ther appears to be another problem in here somewhere.  Every
> Peter> now and then I get a general protect fault with this card and
> Peter> 2.6.27-rc1.  This is on an AMD64 box.  I'm not sure I entirely
> Peter> believe the stack backtrace.
> 
> I recompiled with frame pointers.  Here's another trace.  i believe
> this one :-) This is 2.6.27-rc1 as of 4/8/2008 with my patch applied

I am still not completely happy with the trace, but it at least points a bit
clearer to the source of the problem.

Are you running rt2500pci in managed or adhoc mode?
And when does this bug trigger, when authenticating, associating,
deauthentication or random?

Also could you post some of the rt2500/mac80211 debug messages from the
log from before the actual bug?

Ivo

> general protection fault: 0000 [1] PREEMPT 
> CPU 0 
> Modules linked in: radeon rfcomm l2cap bluetooth sd_mod scsi_mod pcmcia rt2500pci rt2x00pci rt2x00lib led_class mac80211 i2c_piix4 rtc_cmos firewire_ohci snd_hda_intel eeprom_93cx6 rtc_core yenta_socket firewire_core serio_raw usbhid rtc_lib rsrc_nonstatic i2c_core snd_hwdep hid
> Pid: 2181, comm: rt2500pci Not tainted 2.6.27-rc1 #51
> RIP: 0010:[<ffffffff80260c8d>]  [<ffffffff80260c8d>] put_page+0xc/0xd6
> RSP: 0018:ffff88003fbd9bf0  EFLAGS: 00010286
> RAX: 0000000000000000 RBX: fd94ea9eed2c0b41 RCX: 0000000000000000
> RDX: ffff8800352b89c0 RSI: 0000000000000000 RDI: fd94ea9eed2c0b41
> RBP: ffff88003fbd9c00 R08: ffff88003f32e2a0 R09: 0000000000000002
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
> R13: ffff8800352b8014 R14: ffff88003cc0c000 R15: 0000000000000000
> FS:  00007fb7bcdbe6f0(0000) GS:ffffffff8068ae40(0000) knlGS:00000000f7bcf6c0
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 00000000006d20c8 CR3: 000000003527c000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process rt2500pci (pid: 2181, threadinfo ffff88003fbd8000, task ffff88003fb00b00)
> Stack:  0000000000000000 ffff880035283900 ffff88003fbd9c20 ffffffff80482ee8
>  ffff880035283900 ffff88003cc60c00 ffff88003fbd9c40 ffffffff8048358a
>  ffff88003cc60c00 ffff880035283900 ffff88003fbd9c60 ffffffff80482d85
> Call Trace:
>  [<ffffffff80482ee8>] skb_release_data+0x68/0xac
>  [<ffffffff8048358a>] skb_release_all+0x6f/0x73
>  [<ffffffff80482d85>] __kfree_skb+0x11/0x77
>  [<ffffffff80482e11>] kfree_skb+0x26/0x28
>  [<ffffffffa00a8ee4>] ieee80211_sta_rx_queued_mgmt+0xd5f/0xd85 [mac80211]
>  [<ffffffff804835fa>] ? __alloc_skb+0x3b/0x12e
>  [<ffffffff80496f9d>] ? __qdisc_run+0xd1/0x1ea
>  [<ffffffff8048b197>] ? dev_queue_xmit+0x427/0x468
>  [<ffffffff8036b433>] ? delay_tsc+0x25/0xa2
>  [<ffffffff8036b3a5>] ? __delay+0xa/0xc
>  [<ffffffff8036b3c9>] ? __const_udelay+0x22/0x24
>  [<ffffffffa00cf11f>] ? rt2500pci_bbp_check+0x35/0x45 [rt2500pci]
>  [<ffffffffa00aa066>] ieee80211_sta_work+0x99/0x6c3 [mac80211]
>  [<ffffffff8052ae7e>] ? thread_return+0x30/0xa9
>  [<ffffffffa00a9fcd>] ? ieee80211_sta_work+0x0/0x6c3 [mac80211]
>  [<ffffffff8023a2b9>] run_workqueue+0xb2/0x178
>  [<ffffffff8023ac9a>] worker_thread+0xd3/0xe0
>  [<ffffffff8023d9b1>] ? autoremove_wake_function+0x0/0x38
>  [<ffffffff8023abc7>] ? worker_thread+0x0/0xe0
>  [<ffffffff8023d8a1>] kthread+0x49/0x78
>  [<ffffffff8020bc59>] child_rip+0xa/0x11
>  [<ffffffff8023d858>] ? kthread+0x0/0x78
>  [<ffffffff8020bc4f>] ? child_rip+0x0/0x11
> 
> 
> Code: f6 80 38 e0 ff ff 08 74 05 e8 ea a2 2c 00 5e 5b c9 c3 55 48 89 e5 e8 71 ff ff ff c9 31 c0 c3 55 48 89 e5 53 48 89 fb 48 83 ec 08 <f7> 07 00 60 00 00 74 0a e8 05 f9 ff ff e9 b4 00 00 00 ff 4f 08 
> RIP  [<ffffffff80260c8d>] put_page+0xc/0xd6
>  RSP <ffff88003fbd9bf0>
> 

Re: Fixing rt2500pci

[Peter Chubb]

>>>>> "Ivo" == Ivo van Doorn <ivdoorn@gmail.com> writes:

Ivo> On Tuesday 05 August 2008, Peter Chubb wrote:
>> >>>>> "Peter" == Peter Chubb <peterc@gelato.unsw.edu.au> writes:
>> 
Peter> Ther appears to be another problem in here somewhere.  Every
Peter> now and then I get a general protect fault with this card and
Peter> 2.6.27-rc1.  This is on an AMD64 box.  I'm not sure I entirely
Peter> believe the stack backtrace.
>> I recompiled with frame pointers.  Here's another trace.  i believe
>> this one :-) This is 2.6.27-rc1 as of 4/8/2008 with my patch
>> applied

Ivo> I am still not completely happy with the trace, but it at least
Ivo> points a bit clearer to the source of the problem.

You have to ignore the symbols with a question mark.

Ivo> Are you running rt2500pci in managed or adhoc mode?  And when
Ivo> does this bug trigger, when authenticating, associating,
Ivo> deauthentication or random?

Managed; WEP; the bug triggers at random some time after associating.

Ivo> Also could you post some of the rt2500/mac80211 debug messages
Ivo> from the log from before the actual bug?

Will do -- later today.  I dropped back to 2.6.26-rc9 to do real work :-)
 --
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

Re: Fixing rt2500pci

[Peter Chubb]

>>>>> "Ivo" == Ivo van Doorn <ivdoorn@gmail.com> writes:


Ivo> Are you running rt2500pci in managed or adhoc mode?  And when
Ivo> does this bug trigger, when authenticating, associating,
Ivo> deauthentication or random?

Managed mode; the bug happens randomly.

Ivo> Also could you post some of the rt2500/mac80211 debug messages
Ivo> from the log from before the actual bug?

There isn't very much.  Here's another trace plus all messages from
the rt2500 or MAC or PHY.  I can turn on more debugging if you can
suggest what'd be appropriate.  The gap between the `switching to
long barker preamble' message and the OOPS is about half an hour.

I should perhaps mention that the card has difficulty in associating
now: I do ifup and nothing happens unless a different window I force a
reassociation by doing iwconfig wlan0 essid any in a different window
while dhclient is running.



rt2500pci 0000:05:09.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
phy0: Selected rate control algorithm 'pid'
Registered led device: rt2500pci-phy0:radio
phy0: HW CONFIG: freq=2412
ADDRCONF(NETDEV_UP): wlan: link is not ready
phy0: HW CONFIG: freq=2412
phy0: HW CONFIG: freq=2417
phy0: HW CONFIG: freq=2422
phy0: HW CONFIG: freq=2427
phy0: HW CONFIG: freq=2432
phy0: HW CONFIG: freq=2437
phy0: HW CONFIG: freq=2442
phy0: HW CONFIG: freq=2447
phy0: HW CONFIG: freq=2452
phy0: HW CONFIG: freq=2457
phy0: HW CONFIG: freq=2462
phy0: HW CONFIG: freq=2412
phy0: HW CONFIG: freq=2422
wlan: authenticate with AP 00:12:17:68:eb:05
wlan: authenticated
wlan: associate with AP 00:12:17:68:eb:05
wlan: RX AssocResp from 00:12:17:68:eb:05 (capab=0x11 status=0 aid=17)
wlan: associated
phy0: Allocated STA 00:12:17:68:eb:05
phy0: Inserted STA 00:12:17:68:eb:05
ADDRCONF(NETDEV_CHANGE): wlan: link becomes ready
phy0: Removed STA 00:12:17:68:eb:05
phy0: Destroyed STA 00:12:17:68:eb:05
phy0: HW CONFIG: freq=2422
ADDRCONF(NETDEV_UP): wlan: link is not ready
phy0: HW CONFIG: freq=2422
wlan: authenticate with AP 00:12:17:68:eb:05
wlan: authenticated
wlan: associate with AP 00:12:17:68:eb:05
wlan: RX AssocResp from 00:12:17:68:eb:05 (capab=0x11 status=0 aid=17)
wlan: associated
phy0: Allocated STA 00:12:17:68:eb:05
phy0: Inserted STA 00:12:17:68:eb:05
wlan: No ProbeResp from current AP 00:12:17:68:eb:05 - assume out of range
phy0: Removed STA 00:12:17:68:eb:05
ADDRCONF(NETDEV_CHANGE): wlan: link becomes ready
wlan: dropped frame to 00:12:17:68:eb:05 (unauthorized port)
phy0: Destroyed STA 00:12:17:68:eb:05
wlan: dropped frame to 00:12:17:68:eb:05 (unauthorized port)
phy0: HW CONFIG: freq=2422
ADDRCONF(NETDEV_UP): wlan: link is not ready
phy0: HW CONFIG: freq=2422
wlan: authenticate with AP 00:12:17:68:eb:05
wlan: authenticated
wlan: associate with AP 00:12:17:68:eb:05
wlan: RX AssocResp from 00:12:17:68:eb:05 (capab=0x11 status=0 aid=17)
wlan: associated
phy0: Allocated STA 00:12:17:68:eb:05
phy0: Inserted STA 00:12:17:68:eb:05
ADDRCONF(NETDEV_CHANGE): wlan: link becomes ready
wlan: no IPv6 routers present
wlan: CTS protection enabled (BSSID=00:12:17:68:eb:05)
wlan: switched to short barker preamble (BSSID=00:12:17:68:eb:05)
wlan: CTS protection disabled (BSSID=00:12:17:68:eb:05)
wlan: switched to long barker preamble (BSSID=00:12:17:68:eb:05)
**30 minutes gap here***
general protection fault: 0000 [1] PREEMPT 
CPU 0 
Modules linked in: radeon rfcomm l2cap bluetooth tun sd_mod scsi_mod rt2500pci rt2x00pci rt2x00lib led_class pcmcia rtc_cmos firewire_ohci mac80211 snd_hda_intel firewire_core rtc_core yenta_socket i2c_piix4 serio_raw eeprom_93cx6 rtc_lib usbhid rsrc_nonstatic snd_hwdep i2c_core hid
Pid: 2203, comm: rt2500pci Not tainted 2.6.27-rc1 #52
RIP: 0010:[<ffffffff80260c8d>]  [<ffffffff80260c8d>] put_page+0xc/0xd6
RSP: 0018:ffff88003efbfbf0  EFLAGS: 00010286
RAX: 0000000000000000 RBX: a28ff9ca48bf9c98 RCX: 0000000000000000
RDX: ffff8800361ff9c0 RSI: 0000000000000000 RDI: a28ff9ca48bf9c98
RBP: ffff88003efbfc00 R08: ffff88003ef7a2a0 R09: 0000000000000002
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
R13: ffff8800361ff014 R14: ffff88003ef1b000 R15: 0000000000000000
FS:  00007f47264506e0(0000) GS:ffffffff8068ae40(0000) knlGS:00000000f7ba06c0
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00007fff807567f6 CR3: 000000003e2a7000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rt2500pci (pid: 2203, threadinfo ffff88003efbe000, task ffff88003f9d7700)
Stack:  0000000000000000 ffff8800361e7300 ffff88003efbfc20 ffffffff80482ee8
 ffff8800361e7300 ffff88003ef4c7c0 ffff88003efbfc40 ffffffff8048358a
 ffff88003ef4c7c0 ffff8800361e7300 ffff88003efbfc60 ffffffff80482d85
Call Trace:
 [<ffffffff80482ee8>] skb_release_data+0x68/0xac
 [<ffffffff8048358a>] skb_release_all+0x6f/0x73
 [<ffffffff80482d85>] __kfree_skb+0x11/0x77
 [<ffffffff80482e11>] kfree_skb+0x26/0x28
 [<ffffffffa009c1b6>] ieee80211_sta_rx_queued_mgmt+0xd5f/0xd85 [mac80211]
 [<ffffffff804835fa>] ? __alloc_skb+0x3b/0x12e
 [<ffffffff80496f9d>] ? __qdisc_run+0xd1/0x1ea
 [<ffffffff8048b197>] ? dev_queue_xmit+0x427/0x468
 [<ffffffffa0097489>] ? ieee80211_rx_bss_get+0xbb/0xca [mac80211]
 [<ffffffffa00975d4>] ? ieee80211_rx_bss_put+0x2c/0xf3 [mac80211]
 [<ffffffffa009776f>] ? ieee80211_privacy_mismatch+0x9e/0xcd [mac80211]
 [<ffffffffa009d338>] ieee80211_sta_work+0x99/0x6c5 [mac80211]
 [<ffffffff8052ae7e>] ? thread_return+0x30/0xa9
 [<ffffffffa009d29f>] ? ieee80211_sta_work+0x0/0x6c5 [mac80211]
 [<ffffffff8023a2b9>] run_workqueue+0xb2/0x178
 [<ffffffff8023ac9a>] worker_thread+0xd3/0xe0
 [<ffffffff8023d9b1>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023abc7>] ? worker_thread+0x0/0xe0
 [<ffffffff8023d8a1>] kthread+0x49/0x78
 [<ffffffff8020bc59>] child_rip+0xa/0x11
 [<ffffffff8023d858>] ? kthread+0x0/0x78
 [<ffffffff8020bc4f>] ? child_rip+0x0/0x11 [<ffffffff80496f9d>] ? __qdisc_run+0xd1/0x1ea
 [<ffffffff8048b197>] ? dev_queue_xmit+0x427/0x468
 [<ffffffffa0097489>] ? ieee80211_rx_bss_get+0xbb/0xca [mac80211]
 [<ffffffffa00975d4>] ? ieee80211_rx_bss_put+0x2c/0xf3 [mac80211]
 [<ffffffffa009776f>] ? ieee80211_privacy_mismatch+0x9e/0xcd [mac80211]
 [<ffffffffa009d338>] ieee80211_sta_work+0x99/0x6c5 [mac80211]
 [<ffffffff8052ae7e>] ? thread_return+0x30/0xa9
 [<ffffffffa009d29f>] ? ieee80211_sta_work+0x0/0x6c5 [mac80211]
 [<ffffffff8023a2b9>] run_workqueue+0xb2/0x178
 [<ffffffff8023ac9a>] worker_thread+0xd3/0xe0
 [<ffffffff8023d9b1>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8023abc7>] ? worker_thread+0x0/0xe0
 [<ffffffff8023d8a1>] kthread+0x49/0x78
 [<ffffffff8020bc59>] child_rip+0xa/0x11
 [<ffffffff8023d858>] ? kthread+0x0/0x78
 [<ffffffff8020bc4f>] ? child_rip+0x0/0x11


Code: f6 80 38 e0 ff ff 08 74 05 e8 ea a2 2c 00 5e 5b c9 c3 55 48 89
 e5 e8 71 ff 
 ff ff c9 31 c0 c3 55 48 89 e5 53 48 89 fb 48 83 ec 08 <f7> 07 00 60 00 00 74 0a
 e8 05 f9 ff ff e9 b4 00 00 00 ff 4f 08 
RIP  [<ffffffff80260c8d>] put_page+0xc/0xd6
 RSP <ffff88003efbfbf0>
---[ end trace 4f9e6e26b2f3fe71 ]---
--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia