[PATCH 0/3] ath9k: several fixes ported to 2.6.27

[PATCH 0/3] ath9k: several fixes ported to 2.6.27

[Luis R. Rodriguez]

This fixes a few issues seen on MacBook Pros:

http://bugzilla.kernel.org/show_bug.cgi?id=11811

I've ported them to 2.6.27 to help with them being applied sooner.
I've tried to keep them as small as possible. I don't have the
ports for 2.6.28 though I think John will be sending them soon
through his pending-fixes branch.

These are already applied on wireless-testing.

  Luis

[PATCH] ath9k: Fix SW-IOMMU bounce buffer starvation

[Luis R. Rodriguez]

This should fix the SW-IOMMU bounce buffer starvation
seen ok kernel.org bugzilla 11811:

http://bugzilla.kernel.org/show_bug.cgi?id=11811

Users on MacBook Pro 3.1/MacBook v2 would see something like:

DMA: Out of SW-IOMMU space for 4224 bytes at device 0000:0b:00.0

Unfortunately its only easy to trigger on MacBook Pro 3.1/MacBook v2
so far so its difficult to debug (even with swiotlb=force).

We were pci_unmap_single()'ing less bytes than what we called
for with pci_map_single() and as such we were starving
the swiotlb from its 64MB amount of bounce buffers. We remain
consistent and now always use sc->rxbufsize for RX. While at
it we update the beacon DMA maps as well to only use the data
portion of the skb, previous to this we were pci_map_single()'ing
more data for beaconing than what we tell the hardware it can use,
therefore pushing more iotlb abuse.

Still not sure why this is so easily triggerable on
MacBook Pro 3.1, it may be the hardware configuration
tends to use more memory > 3GB mark for DMA.

Signed-off-by: Maciej Zenczykowski <zenczykowski@gmail.com>
Signed-off-by: Bennyam Malavazi <Bennyam.Malavazi@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath9k/recv.c |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath9k/recv.c b/drivers/net/wireless/ath9k/recv.c
index 20ddb7a..4d23827 100644
--- a/drivers/net/wireless/ath9k/recv.c
+++ b/drivers/net/wireless/ath9k/recv.c
@@ -1011,7 +1011,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
 
 		pci_dma_sync_single_for_cpu(sc->pdev,
 					    bf->bf_buf_addr,
-					    skb_tailroom(skb),
+					    sc->sc_rxbufsize,
 					    PCI_DMA_FROMDEVICE);
 		pci_unmap_single(sc->pdev,
 				 bf->bf_buf_addr,
@@ -1303,8 +1303,7 @@ dma_addr_t ath_skb_map_single(struct ath_softc *sc,
 	 * NB: do NOT use skb->len, which is 0 on initialization.
 	 * Use skb's entire data area instead.
 	 */
-	*pa = pci_map_single(sc->pdev, skb->data,
-		skb_end_pointer(skb) - skb->head, direction);
+	*pa = pci_map_single(sc->pdev, skb->data, sc->sc_rxbufsize, direction);
 	return *pa;
 }
 
@@ -1314,6 +1313,5 @@ void ath_skb_unmap_single(struct ath_softc *sc,
 			  dma_addr_t *pa)
 {
 	/* Unmap skb's entire data area */
-	pci_unmap_single(sc->pdev, *pa,
-		skb_end_pointer(skb) - skb->head, direction);
+	pci_unmap_single(sc->pdev, *pa, sc->sc_rxbufsize, direction);
 }
-- 
1.5.6.rc2.15.g457bb.dirty

[PATCH] ath9k: correct expected max RX buffer size

[Luis R. Rodriguez]

We should only tell the hardware its capable of DMA'ing
to us only what we asked dev_alloc_skb(). Prior to this
it is possible a large RX'd frame could have corrupted
DMA data but for us but we were saved only because we
were previously also pci_map_single()'ing the same large
value. The issue prior to this though was we were unmapping
a smaller amount which the prior DMA patch fixed.

Signed-off-by: Bennyam Malavazi <Bennyam.Malavazi@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath9k/recv.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath9k/recv.c b/drivers/net/wireless/ath9k/recv.c
index 4d23827..0941589 100644
--- a/drivers/net/wireless/ath9k/recv.c
+++ b/drivers/net/wireless/ath9k/recv.c
@@ -52,7 +52,7 @@ static void ath_rx_buf_link(struct ath_softc *sc, struct ath_buf *bf)
 	/* setup rx descriptors */
 	ath9k_hw_setuprxdesc(ah,
 			     ds,
-			     skb_tailroom(skb),   /* buffer size */
+			     sc->sc_rxbufsize,
 			     0);
 
 	if (sc->sc_rxlink == NULL)
-- 
1.5.6.rc2.15.g457bb.dirty

[PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Luis R. Rodriguez]

We would get an oops on RX on -ENOMEM by passing
NULL to the hardware on ath_rx_buf_link(). The oops
would look something like this:

ath_rx_tasklet
...
RIP: ath_rx_buf_link

We correct this by handling the allocation for the next
skb we will put in our RX tail directly on the ath_rx_tasklet()
*prior* to sending up the last hardware processed
skb. If we run out of memory this gauranteees we have
skbs to work with while it simply drops new received
frames.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath9k/recv.c |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath9k/recv.c b/drivers/net/wireless/ath9k/recv.c
index 0941589..a4f92b2 100644
--- a/drivers/net/wireless/ath9k/recv.c
+++ b/drivers/net/wireless/ath9k/recv.c
@@ -441,18 +441,16 @@ static void ath_rx_requeue(struct ath_softc *sc, struct sk_buff *skb)
  */
 static int ath_rx_indicate(struct ath_softc *sc,
 			   struct sk_buff *skb,
+			   struct sk_buff *nskb,
 			   struct ath_recv_status *status,
 			   u16 keyix)
 {
 	struct ath_buf *bf = ATH_RX_CONTEXT(skb)->ctx_rxbuf;
-	struct sk_buff *nskb;
 	int type;
 
 	/* indicate frame to the stack, which will free the old skb. */
 	type = ath__rx_indicate(sc, skb, status, keyix);
 
-	/* allocate a new skb and queue it to for H/W processing */
-	nskb = ath_rxbuf_alloc(sc, sc->sc_rxbufsize);
 	if (nskb != NULL) {
 		bf->bf_mpdu = nskb;
 		bf->bf_buf_addr = ath_skb_map_single(sc,
@@ -741,6 +739,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
 	struct ath_desc *ds;
 	struct ieee80211_hdr *hdr;
 	struct sk_buff *skb = NULL;
+	struct sk_buff *nskb = NULL;
 	struct ath_recv_status rx_status;
 	struct ath_hal *ah = sc->sc_ah;
 	int type, rx_processed = 0;
@@ -963,6 +962,17 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
 		 */
 		if (sc->sc_rxbufsize < ds->ds_rxstat.rs_datalen)
 			goto rx_next;
+
+		/* allocate a new skb and queue it to for H/W processing */
+		nskb = ath_rxbuf_alloc(sc, sc->sc_rxbufsize);
+
+		/* Diregard current RX'd frame and reuse the old skb */
+		if (!nskb) {
+			list_move_tail(&bf->list, &sc->sc_rxbuf);
+			ath_rx_buf_link(sc, bf);
+			goto rx_next;
+		}
+
 		/*
 		 * Sync and unmap the frame.  At this point we're
 		 * committed to passing the sk_buff somewhere so
@@ -1052,7 +1062,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
 
 		/* Pass frames up to the stack. */
 
-		type = ath_rx_indicate(sc, skb,
+		type = ath_rx_indicate(sc, skb, nskb,
 			&rx_status, ds->ds_rxstat.rs_keyix);
 
 		/*
-- 
1.5.6.rc2.15.g457bb.dirty

Re: [ath9k-devel] [PATCH 0/3] ath9k: several fixes ported to 2.6.27

[Luis R. Rodriguez]

On Tue, Dec 2, 2008 at 12:51 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> This fixes a few issues seen on MacBook Pros:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=11811
>
> I've ported them to 2.6.27 to help with them being applied sooner.
> I've tried to keep them as small as possible. I don't have the
> ports for 2.6.28 though I think John will be sending them soon
> through his pending-fixes branch.
>
> These are already applied on wireless-testing.

Oh sorry, I noticed patch 2 and 3 didn't go with the subject to
indicate their order. The order they should be applied in is:

0001-ath9k-Fix-SW-IOMMU-bounce-buffer-starvation.patch
0002-ath9k-correct-expected-max-RX-buffer-size.patch
0003-ath9k-Handle-ENOMEM-on-RX-gracefully.patch

You can also find these here:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2008-11-22/27-IOMMU-01/

  Luis

Re: [stable] [PATCH 0/3] ath9k: several fixes ported to 2.6.27

[Greg KH]

On Tue, Dec 02, 2008 at 12:51:19PM -0800, Luis R. Rodriguez wrote:
> This fixes a few issues seen on MacBook Pros:
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=11811
> 
> I've ported them to 2.6.27 to help with them being applied sooner.

What do you mean by "sooner"?  They need to be in Linus's tree before we
can add them to the 2.6.27-stable tree.  Please let us know when that
happens, and what the git ids of them are, so we can add them to the
next -stable release.

thanks,

greg k-h

Re: [stable] [PATCH 0/3] ath9k: several fixes ported to 2.6.27

[Luis R. Rodriguez]

On Tue, Dec 2, 2008 at 1:27 PM, Greg KH <greg@kroah.com> wrote:
> On Tue, Dec 02, 2008 at 12:51:19PM -0800, Luis R. Rodriguez wrote:
>> This fixes a few issues seen on MacBook Pros:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=11811
>>
>> I've ported them to 2.6.27 to help with them being applied sooner.
>
> What do you mean by "sooner"?  They need to be in Linus's tree before we
> can add them to the 2.6.27-stable tree.  Please let us know when that
> happens, and what the git ids of them are, so we can add them to the
> next -stable release.

Heh, well once applied there it may not apply on 27, so by sooner I
mean that you don't have to do backport work as I did it for you.

  Luis

Re: [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Greg KH]

I don't see this patch upstream in Linus's tree.  Am I just missing it
and if so, do you know the git commit id?

thanks,

greg k-h


On Tue, Dec 02, 2008 at 12:51:22PM -0800, Luis R. Rodriguez wrote:
> We would get an oops on RX on -ENOMEM by passing
> NULL to the hardware on ath_rx_buf_link(). The oops
> would look something like this:
> 
> ath_rx_tasklet
> ...
> RIP: ath_rx_buf_link
> 
> We correct this by handling the allocation for the next
> skb we will put in our RX tail directly on the ath_rx_tasklet()
> *prior* to sending up the last hardware processed
> skb. If we run out of memory this gauranteees we have
> skbs to work with while it simply drops new received
> frames.
> 
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>  drivers/net/wireless/ath9k/recv.c |   18 ++++++++++++++----
>  1 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath9k/recv.c b/drivers/net/wireless/ath9k/recv.c
> index 0941589..a4f92b2 100644
> --- a/drivers/net/wireless/ath9k/recv.c
> +++ b/drivers/net/wireless/ath9k/recv.c
> @@ -441,18 +441,16 @@ static void ath_rx_requeue(struct ath_softc *sc, struct sk_buff *skb)
>   */
>  static int ath_rx_indicate(struct ath_softc *sc,
>  			   struct sk_buff *skb,
> +			   struct sk_buff *nskb,
>  			   struct ath_recv_status *status,
>  			   u16 keyix)
>  {
>  	struct ath_buf *bf = ATH_RX_CONTEXT(skb)->ctx_rxbuf;
> -	struct sk_buff *nskb;
>  	int type;
>  
>  	/* indicate frame to the stack, which will free the old skb. */
>  	type = ath__rx_indicate(sc, skb, status, keyix);
>  
> -	/* allocate a new skb and queue it to for H/W processing */
> -	nskb = ath_rxbuf_alloc(sc, sc->sc_rxbufsize);
>  	if (nskb != NULL) {
>  		bf->bf_mpdu = nskb;
>  		bf->bf_buf_addr = ath_skb_map_single(sc,
> @@ -741,6 +739,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
>  	struct ath_desc *ds;
>  	struct ieee80211_hdr *hdr;
>  	struct sk_buff *skb = NULL;
> +	struct sk_buff *nskb = NULL;
>  	struct ath_recv_status rx_status;
>  	struct ath_hal *ah = sc->sc_ah;
>  	int type, rx_processed = 0;
> @@ -963,6 +962,17 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
>  		 */
>  		if (sc->sc_rxbufsize < ds->ds_rxstat.rs_datalen)
>  			goto rx_next;
> +
> +		/* allocate a new skb and queue it to for H/W processing */
> +		nskb = ath_rxbuf_alloc(sc, sc->sc_rxbufsize);
> +
> +		/* Diregard current RX'd frame and reuse the old skb */
> +		if (!nskb) {
> +			list_move_tail(&bf->list, &sc->sc_rxbuf);
> +			ath_rx_buf_link(sc, bf);
> +			goto rx_next;
> +		}
> +
>  		/*
>  		 * Sync and unmap the frame.  At this point we're
>  		 * committed to passing the sk_buff somewhere so
> @@ -1052,7 +1062,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
>  
>  		/* Pass frames up to the stack. */
>  
> -		type = ath_rx_indicate(sc, skb,
> +		type = ath_rx_indicate(sc, skb, nskb,
>  			&rx_status, ds->ds_rxstat.rs_keyix);
>  
>  		/*
> -- 
> 1.5.6.rc2.15.g457bb.dirty
> 
> _______________________________________________
> stable mailing list
> stable@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/stable

Re: [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Luis R. Rodriguez]

On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
> I don't see this patch upstream in Linus's tree.  Am I just missing it
> and if so, do you know the git commit id?

Nope sorry, John has yet to send his pending-fixes branch to davem and
so forth, which would contain it AFAICT. Please correct me if I'm
wrong John.

  Luis

Re: [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[John W. Linville]

On Tue, Dec 02, 2008 at 04:20:32PM -0800, Luis R. Rodriguez wrote:
> On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
> > I don't see this patch upstream in Linus's tree.  Am I just missing it
> > and if so, do you know the git commit id?
> 
> Nope sorry, John has yet to send his pending-fixes branch to davem and
> so forth, which would contain it AFAICT. Please correct me if I'm
> wrong John.

It has been sent, and Dave sent his pull request to Linus today
(or maybe yesterday).  I'll try to dig-up the commit IDs tomorrow.

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: [ath9k-devel] [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Luis R. Rodriguez]

On Tue, Dec 2, 2008 at 4:24 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, Dec 02, 2008 at 04:20:32PM -0800, Luis R. Rodriguez wrote:
>> On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
>> > I don't see this patch upstream in Linus's tree.  Am I just missing it
>> > and if so, do you know the git commit id?
>>
>> Nope sorry, John has yet to send his pending-fixes branch to davem and
>> so forth, which would contain it AFAICT. Please correct me if I'm
>> wrong John.
>
> It has been sent, and Dave sent his pull request to Linus today
> (or maybe yesterday).  I'll try to dig-up the commit IDs tomorrow.

Greg, I see two of these patches in 2.6.27-stable review patch but the
one in this subject was not applied, any specific reason or was it
just missed?

  Luis

Re: [ath9k-devel] [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Greg KH]

On Wed, Dec 03, 2008 at 12:19:22PM -0800, Luis R. Rodriguez wrote:
> On Tue, Dec 2, 2008 at 4:24 PM, John W. Linville <linville@tuxdriver.com> wrote:
> > On Tue, Dec 02, 2008 at 04:20:32PM -0800, Luis R. Rodriguez wrote:
> >> On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
> >> > I don't see this patch upstream in Linus's tree.  Am I just missing it
> >> > and if so, do you know the git commit id?
> >>
> >> Nope sorry, John has yet to send his pending-fixes branch to davem and
> >> so forth, which would contain it AFAICT. Please correct me if I'm
> >> wrong John.
> >
> > It has been sent, and Dave sent his pull request to Linus today
> > (or maybe yesterday).  I'll try to dig-up the commit IDs tomorrow.
> 
> Greg, I see two of these patches in 2.6.27-stable review patch but the
> one in this subject was not applied, any specific reason or was it
> just missed?

It was not applied because it was not yet in Linus's tree, which is a
requirement for it to go into the 2.6.27-stable tree.

thanks,

greg k-h

Re: [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[John W. Linville]

On Tue, Dec 02, 2008 at 07:24:04PM -0500, John W. Linville wrote:
> On Tue, Dec 02, 2008 at 04:20:32PM -0800, Luis R. Rodriguez wrote:
> > On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
> > > I don't see this patch upstream in Linus's tree.  Am I just missing it
> > > and if so, do you know the git commit id?
> > 
> > Nope sorry, John has yet to send his pending-fixes branch to davem and
> > so forth, which would contain it AFAICT. Please correct me if I'm
> > wrong John.
> 
> It has been sent, and Dave sent his pull request to Linus today
> (or maybe yesterday).  I'll try to dig-up the commit IDs tomorrow.

Hmmm...I seem to have sent this to -next instead.  Since it fixes an
Oops, I guess I can requeue for 2.6.28.

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: [ath9k-devel] [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Luis R. Rodriguez]

On Wed, Dec 3, 2008 at 1:22 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, Dec 02, 2008 at 07:24:04PM -0500, John W. Linville wrote:
>> On Tue, Dec 02, 2008 at 04:20:32PM -0800, Luis R. Rodriguez wrote:
>> > On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
>> > > I don't see this patch upstream in Linus's tree.  Am I just missing it
>> > > and if so, do you know the git commit id?
>> >
>> > Nope sorry, John has yet to send his pending-fixes branch to davem and
>> > so forth, which would contain it AFAICT. Please correct me if I'm
>> > wrong John.
>>
>> It has been sent, and Dave sent his pull request to Linus today
>> (or maybe yesterday).  I'll try to dig-up the commit IDs tomorrow.
>
> Hmmm...I seem to have sent this to -next instead.  Since it fixes an
> Oops, I guess I can requeue for 2.6.28.

Pretty please :)

 Luis