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

[ath9k-devel] [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 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 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

[ath9k-devel] [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: 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: 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

[ath9k-devel] [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] 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] 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

[ath9k-devel] [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

[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

[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

[ath9k-devel] [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 at linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/stable

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

[ath9k-devel] [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

[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

[ath9k-devel] [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 at tuxdriver.com			of your literate lifestyle.

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.

[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

[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

[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: [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

[ath9k-devel] [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 at tuxdriver.com			of your literate lifestyle.

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.

[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

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

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

[Brian]

Luis,
I tried to respond to your comment in bug 12110 but do not have a id yet.

Does this patch fix this bug?


Here is my response


I have the same problem but with wireless testing on a 2.6.28-rc6-wl kernel.
I can run for hours if I do not use the wireless heavily.
But will crash within 10mins if I use NX.
(I have the NX parm turned on in the kernel)
I also get the same symptoms re a ping that will just stop/start,
directly before a crash. Also it starts to use my swap file. I NEVER use
swap normally.
Would you like me to apply the same patch and see if I can get some message?


Can I get a patch for 2.6.28-rc6-wl ?


Wireless Statistics
Sent :891261
TX Packets Dropped :21
Received :878290
RX Packets Dropped :1576
Errors :3531

Brian

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

[Brian]

Luis,
I tried to respond to your comment in bug 12110 but do not have a id yet.

Does this patch fix this bug?


Here is my response


I have the same problem but with wireless testing on a 2.6.28-rc6-wl kernel.
I can run for hours if I do not use the wireless heavily.
But will crash within 10mins if I use NX.
(I have the NX parm turned on in the kernel)
I also get the same symptoms re a ping that will just stop/start,
directly before a crash. Also it starts to use my swap file. I NEVER use
swap normally.
Would you like me to apply the same patch and see if I can get some message?


Can I get a patch for 2.6.28-rc6-wl ?


Wireless Statistics
Sent :891261
TX Packets Dropped :21
Received :878290
RX Packets Dropped :1576
Errors :3531

Brian

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

[Luis R. Rodriguez]

On Wed, Dec 03, 2008 at 02:59:21PM -0800, Brian wrote:
> Luis,
> I tried to respond to your comment in bug 12110 but do not have a id yet.
> 
> Does this patch fix this bug?
> 
> 
> Here is my response
> 
> 
> I have the same problem but with wireless testing on a 2.6.28-rc6-wl kernel.
> I can run for hours if I do not use the wireless heavily.
> But will crash within 10mins if I use NX.
> (I have the NX parm turned on in the kernel)
> I also get the same symptoms re a ping that will just stop/start,
> directly before a crash. Also it starts to use my swap file. I NEVER use
> swap normally.
> Would you like me to apply the same patch and see if I can get some message?
> 
> 
> Can I get a patch for 2.6.28-rc6-wl ?

wireless-testing is now on 2.6.28-rc7, please do a git pull and
recompile and test that. It has some critical fixes for ath9k.

  Luis

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

[Luis R. Rodriguez]

On Wed, Dec 03, 2008 at 02:59:21PM -0800, Brian wrote:
> Luis,
> I tried to respond to your comment in bug 12110 but do not have a id yet.
> 
> Does this patch fix this bug?
> 
> 
> Here is my response
> 
> 
> I have the same problem but with wireless testing on a 2.6.28-rc6-wl kernel.
> I can run for hours if I do not use the wireless heavily.
> But will crash within 10mins if I use NX.
> (I have the NX parm turned on in the kernel)
> I also get the same symptoms re a ping that will just stop/start,
> directly before a crash. Also it starts to use my swap file. I NEVER use
> swap normally.
> Would you like me to apply the same patch and see if I can get some message?
> 
> 
> Can I get a patch for 2.6.28-rc6-wl ?

wireless-testing is now on 2.6.28-rc7, please do a git pull and
recompile and test that. It has some critical fixes for ath9k.

  Luis

[ath9k-devel] 2.6.28-rc7-wl

[Brian]

Luis,
> 
> wireless-testing is now on 2.6.28-rc7, please do a git pull and
> recompile and test that. It has some critical fixes for ath9k.
> 
Downloaded and installed, I had done a git-pull a few hours before and
it was not there:)

I set up my system with NX running and was waiting to be up 2hours.
Unfortunately it only made 1:50.
Still this is bundles better than the 10mins I was getting.

Some observations:

1) wpa_supplicant no longer chews up cpu/mem. It started and then did
nothing from then on. It used to be in the top 5 on htop.

2) I used to get a huge number of receive errors
 This is what I started with Errors :3708
 After an hour I had         Errors :3746

3) Towards the end the memory usage was creeping, slightly, up but no
where near the swap file.


As suggested by others I did have a console running, but I was
monitoring htop(to see if it started to use the swap) when it went.
So I have no further diagnostics.

When I did the compile it came up and asked me if I wanted the new
diagnostic facility for the driver and I just pressed enter.
Happy to go back and recompile(or can I turn it on).

If I turn it on do you have a methodology to use it?

Thanks for the great improvement,
Brian

2.6.28-rc7-wl

[Brian]

Luis,
> 
> wireless-testing is now on 2.6.28-rc7, please do a git pull and
> recompile and test that. It has some critical fixes for ath9k.
> 
Downloaded and installed, I had done a git-pull a few hours before and
it was not there:)

I set up my system with NX running and was waiting to be up 2hours.
Unfortunately it only made 1:50.
Still this is bundles better than the 10mins I was getting.

Some observations:

1) wpa_supplicant no longer chews up cpu/mem. It started and then did
nothing from then on. It used to be in the top 5 on htop.

2) I used to get a huge number of receive errors
 This is what I started with Errors :3708
 After an hour I had         Errors :3746

3) Towards the end the memory usage was creeping, slightly, up but no
where near the swap file.


As suggested by others I did have a console running, but I was
monitoring htop(to see if it started to use the swap) when it went.
So I have no further diagnostics.

When I did the compile it came up and asked me if I wanted the new
diagnostic facility for the driver and I just pressed enter.
Happy to go back and recompile(or can I turn it on).

If I turn it on do you have a methodology to use it?

Thanks for the great improvement,
Brian

[ath9k-devel] 2.6.28-rc7-wl

[Luis R. Rodriguez]

On Wed, Dec 03, 2008 at 11:59:07PM -0800, Brian wrote:
> 
> 
> Luis,
> >
> > wireless-testing is now on 2.6.28-rc7, please do a git pull and
> > recompile and test that. It has some critical fixes for ath9k.
> >
> Downloaded and installed, I had done a git-pull a few hours before and
> it was not there:)
> 
> I set up my system with NX running and was waiting to be up 2hours.
> Unfortunately it only made 1:50.

What do you mean Brian, did it crash? What happened?

  Luis

Re: 2.6.28-rc7-wl

[Luis R. Rodriguez]

On Wed, Dec 03, 2008 at 11:59:07PM -0800, Brian wrote:
> 
> 
> Luis,
> >
> > wireless-testing is now on 2.6.28-rc7, please do a git pull and
> > recompile and test that. It has some critical fixes for ath9k.
> >
> Downloaded and installed, I had done a git-pull a few hours before and
> it was not there:)
> 
> I set up my system with NX running and was waiting to be up 2hours.
> Unfortunately it only made 1:50.

What do you mean Brian, did it crash? What happened?

  Luis

[ath9k-devel] 2.6.28-rc7-wl

[Luis R. Rodriguez]

On Thu, Dec 04, 2008 at 03:38:09PM -0800, Brian wrote:
> 
> 
> Luis,
> 
> >> So I think the driver could be fine, it could be application specific.
> >> Will also do a search of the NX site and see if they have any problems.
> >>
> >> Will let you know how I go.
> >
> > I see.. What is NX?
> http://www.nomachine.com/
> NX is really great and is easily the best remote control software.
> While I can get by with krdc I want to use NX if I can.
> 
> We run tests against ath9k over hours too and
> > I don't think we've seen this memory hog issue. But if your userspace
> > application is hogging up application your kernel shoulod not panic,
> > unless of course some -ENOMEM as part of your drivers is not being
> > handled correctly. But the patches merged recently actually handle this
> > for ath9k :) I at least have tested it with mem=200 and even using the
> > swiotlb.
> >
> Yes I saw that you had included the -ENOMEM fix, so I was very hopeful
> that the problem would go away.
> I must say the difference between rc6 and rc7 is really significant.
> Things are quicker and more stable for all the normal operations.
> I just do not see what is different about NX, I might try running
> wireshark on it. If you could fire up NX and it fails then at least we
> could say that it is not specific to my machine.
> I should also point out that when researching this problem on the web I
> found that hundreds of people were having the same freezing problem.
> 
> My krdc has been running for 30mins with no problems, but the memory is
> going up.
> 
> Back in a bit

So do some other test -- run bitorrent, or iperf. That should rule out
ath9k.

To test if its NX try testing it over a wired ethernet connection.

  Luis

Re: 2.6.28-rc7-wl

[Luis R. Rodriguez]

On Thu, Dec 04, 2008 at 03:38:09PM -0800, Brian wrote:
> 
> 
> Luis,
> 
> >> So I think the driver could be fine, it could be application specific.
> >> Will also do a search of the NX site and see if they have any problems.
> >>
> >> Will let you know how I go.
> >
> > I see.. What is NX?
> http://www.nomachine.com/
> NX is really great and is easily the best remote control software.
> While I can get by with krdc I want to use NX if I can.
> 
> We run tests against ath9k over hours too and
> > I don't think we've seen this memory hog issue. But if your userspace
> > application is hogging up application your kernel shoulod not panic,
> > unless of course some -ENOMEM as part of your drivers is not being
> > handled correctly. But the patches merged recently actually handle this
> > for ath9k :) I at least have tested it with mem=200 and even using the
> > swiotlb.
> >
> Yes I saw that you had included the -ENOMEM fix, so I was very hopeful
> that the problem would go away.
> I must say the difference between rc6 and rc7 is really significant.
> Things are quicker and more stable for all the normal operations.
> I just do not see what is different about NX, I might try running
> wireshark on it. If you could fire up NX and it fails then at least we
> could say that it is not specific to my machine.
> I should also point out that when researching this problem on the web I
> found that hundreds of people were having the same freezing problem.
> 
> My krdc has been running for 30mins with no problems, but the memory is
> going up.
> 
> Back in a bit

So do some other test -- run bitorrent, or iperf. That should rule out
ath9k.

To test if its NX try testing it over a wired ethernet connection.

  Luis

[ath9k-devel] 2.6.28-rc7-wl

[Brian]

Luis,
> So do some other test -- run bitorrent, or iperf. That should rule out
> ath9k.
> 
Yes I was trying that, in the process of setting up ftp.

> To test if its NX try testing it over a wired ethernet connection.
> 
Yes, I should have thought of that, however I have problems with my eth0
port.

Anyway while looking around the nomachine site I found that my version
of NX was pretty old. So I downloaded the latest.

Some observations

1) I have been up for over an hour on NX
2) The number of errors being generated  are a LOT less, I am collecting
stats.
3) I have changed the bandwidth back to 20mhz so I am only getting 54Mbs
at the moment.

So the main reason I upgraded was because I felt that NX was causing the
large number of TX/RX errors. I think has proved correct, but I will not
know for sure until I put the bandwidth back up to 40mhz.

If this proves to be correct then I think the driver has a problem as
there is no way that errors should cause such a hard lockup.
So my question is how does the driver handle the fact that packets go
missing? Or is this problem handled further up in the tcp stack.

Brian

[ath9k-devel] 2.6.28-rc7-wl

[Luis R. Rodriguez]

On Fri, Dec 05, 2008 at 05:01:53PM -0800, Brian wrote:
> 
> 
> Luis,
> > So do some other test -- run bitorrent, or iperf. That should rule out
> > ath9k.
> >
> Yes I was trying that, in the process of setting up ftp.
> 
> > To test if its NX try testing it over a wired ethernet connection.
> >
> Yes, I should have thought of that, however I have problems with my eth0
> port.
> 
> Anyway while looking around the nomachine site I found that my version
> of NX was pretty old. So I downloaded the latest.
> 
> Some observations
> 
> 1) I have been up for over an hour on NX

Lets stop talking about NX.

> 2) The number of errors being generated  are a LOT less, I am collecting
> stats.
> 3) I have changed the bandwidth back to 20mhz so I am only getting 54Mbs
> at the moment.

You should be able to get more than 54Mbps on HT20 (802.11n HT20),
the theoretical max for HT20 with short guard interval is 144 Mbit/s,
the theoretical max for HT20 with long guard interval is 130 Mbps/s --
using only 2 stream. Your card should be 2-stream. For details of
how to get this information please see:

http://wireless.kernel.org/en/developers/Documentation/ieee80211/802.11n#MCSRates

This doesn't mean you should get these, but it means the card can use
these target rates for TX / RX, the actual throughput values seen will
be different but can be higher than 54Mbps. Just to give you an idea
with 802.11g I usually get highest about 24Mbps in practice.

Please run tests with UDP and TCP with iperf. You can do with by setting
an iperf server with a station connected via Gibabit ethernet on the AP
and then having the iperf client send data to the station. Do this then
the other way around, having the iperf server on the wireless station and
have the station send data to you.

Right now we're running some interoperability tests with different APs
so we should hopefully start seeing issues perhaps users are reporting
that we are not. What AP do you have?

> So the main reason I upgraded was because I felt that NX was causing the
> large number of TX/RX errors. I think has proved correct, but I will not
> know for sure until I put the bandwidth back up to 40mhz.

It seems easier to run long tests with things like iperf no?

> If this proves to be correct then I think the driver has a problem as
> there is no way that errors should cause such a hard lockup.
> So my question is how does the driver handle the fact that packets go
> missing?

You mean that didn't get on the other end? It retransmits.

> Or is this problem handled further up in the tcp stack.

If the wireless frame didn't get to the AP the AP doesn't send an ACK
and the STA retries. If using 802.11n AMPDU (the usual case for
aggregation) then the STA will issue a block ack request, send data
the AP sends a Block ACK in which it has a bitmap which indicates which
frames went through and which never reached the AP. The STA then
retransmits the frames that the bitmap indicates failed.

TCP is upper layer, so that's separate, but you can still have TCP
retransmissions.

  Luis

[ath9k-devel] 2.6.28-rc7-wl

[Brian]

Luis,
> 
> Lets stop talking about NX.
> 
OK, just using that because I knew it was braking things.

>> 2) The number of errors being generated  are a LOT less, I am collecting
>> stats.
>> 3) I have changed the bandwidth back to 20mhz so I am only getting 54Mbs
>> at the moment.
> 
> You should be able to get more than 54Mbps on HT20 (802.11n HT20),
> the theoretical max for HT20 with short guard interval is 144 Mbit/s,
> the theoretical max for HT20 with long guard interval is 130 Mbps/s --
> using only 2 stream. Your card should be 2-stream. For details of
> how to get this information please see:
> 
> http://wireless.kernel.org/en/developers/Documentation/ieee80211/802.11n#MCSRates
> 
> This doesn't mean you should get these, but it means the card can use
> these target rates for TX / RX, the actual throughput values seen will
> be different but can be higher than 54Mbps. Just to give you an idea
> with 802.11g I usually get highest about 24Mbps in practice.
Thanks for the above will look into it.

> 
> Please run tests with UDP and TCP with iperf. You can do with by setting
> an iperf server with a station connected via Gibabit ethernet on the AP
> and then having the iperf client send data to the station. Do this then
> the other way around, having the iperf server on the wireless station and
> have the station send data to you.
> 
I did not know about iperf. Downloading now.

> Right now we're running some interoperability tests with different APs
> so we should hopefully start seeing issues perhaps users are reporting
> that we are not. What AP do you have?
> 
Product Page: DIR-655
Firmware Version: 1.20WW
Hardware Version: A3
Product Page: DIR-655


>> So the main reason I upgraded was because I felt that NX was causing the
>> large number of TX/RX errors. I think has proved correct, but I will not
>> know for sure until I put the bandwidth back up to 40mhz.
> 
> It seems easier to run long tests with things like iperf no?
> 
Agreed.
> 
> If the wireless frame didn't get to the AP the AP doesn't send an ACK
> and the STA retries. If using 802.11n AMPDU (the usual case for
> aggregation) then the STA will issue a block ack request, send data
> the AP sends a Block ACK in which it has a bitmap which indicates which
> frames went through and which never reached the AP. The STA then
> retransmits the frames that the bitmap indicates failed.
> 
Understand that but What I am querying is if some buffer or other does
not get cleared somewhere. Still, lets not speculate lets see what
happens with your testing:)

Will let you know when I have iperf set up.

Brian

[ath9k-devel] 2.6.28-rc7-wl

[Brian]

Luis,
The good news is the network has been working for the last 13 hours:)
The only significant change I have made to the router is that I have
forced it to go to channel 6.
My other settings are auto for the bit rate and 40Mhz for the bandwidth.
The router is also set to pick either 11n or 11g.

For some reason the router is telling me that it has picked 11g for both
machines? The one that is only 11g capable is running at 54Mbs but the
11n one is running at 14mcs or 130Mbs. I did not know you could get 130
out of an 11g.
My point is that if I want to test 11n again I will probably have to buy
a pci card and convert the other machine as well.

Will let you know how I go.
Will keep upgrading the kernel as they become available.
Thanks,
Brian

[ath9k-devel] 2.6.28-rc7-wl

[Luis R. Rodriguez]

On Sat, Dec 06, 2008 at 05:28:01PM -0800, Brian wrote:
> 
> 
> Luis,
> The good news is the network has been working for the last 13 hours:)
> The only significant change I have made to the router is that I have
> forced it to go to channel 6.
> My other settings are auto for the bit rate and 40Mhz for the bandwidth.
> The router is also set to pick either 11n or 11g.
> 
> For some reason the router is telling me that it has picked 11g for both
> machines? The one that is only 11g capable is running at 54Mbs but the
> 11n one is running at 14mcs or 130Mbs.

Good to hear thinkgs are going well.

> I did not know you could get 130
> out of an 11g.

You can't.

> My point is that if I want to test 11n again I will probably have to buy
> a pci card and convert the other machine as well.

To get the max benefit of your 11n connection I'd say go greenfield (enable only 11n,
no backward compatibility). Now to test 11n (even if you do have legacy
support enabled) you just have to have the 11n STA send or receive data
from a STA connected to the AP via an ethernet cable. That's all.

  Luis

[ath9k-devel] patch ath9k-correct-expected-max-rx-buffer-size.patch added to 2.6.27-stable tree

[gregkh at suse.de]

This is a note to let you know that we have just queued up the patch titled

    Subject: ath9k: correct expected max RX buffer size

to the 2.6.27-stable tree.  Its filename is

    ath9k-correct-expected-max-rx-buffer-size.patch

A git repo of this tree can be found at 
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

[ath9k-devel] patch ath9k-fix-sw-iommu-bounce-buffer-starvation.patch added to 2.6.27-stable tree

[gregkh at suse.de]

This is a note to let you know that we have just queued up the patch titled

    Subject: ath9k: Fix SW-IOMMU bounce buffer starvation

to the 2.6.27-stable tree.  Its filename is

    ath9k-fix-sw-iommu-bounce-buffer-starvation.patch

A git repo of this tree can be found at 
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

[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: [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: [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

[ath9k-devel] [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

[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

[ath9k-devel] [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 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