mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
To: <stable@kernel.org>
Cc: <ath9k-devel@venema.h4ckr.net>, <linux-wireless@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <sfr@canb.auug.org.au>,
	"Luis R. Rodriguez" <lrodriguez@atheros.com>,
	Maciej Zenczykowski <zenczykowski@gmail.com>,
	Bennyam Malavazi <Bennyam.Malavazi@atheros.com>
Subject: [PATCH] ath9k: Fix SW-IOMMU bounce buffer starvation
Date: Tue, 2 Dec 2008 12:51:20 -0800	[thread overview]
Message-ID: <1228251082-11677-2-git-send-email-lrodriguez@atheros.com> (raw)
In-Reply-To: <1228251082-11677-1-git-send-email-lrodriguez@atheros.com>

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


  reply	other threads:[~2008-12-02 20:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-02 20:51 [PATCH 0/3] ath9k: several fixes ported to 2.6.27 Luis R. Rodriguez
2008-12-02 20:51 ` Luis R. Rodriguez [this message]
2008-12-02 20:51   ` [PATCH] ath9k: correct expected max RX buffer size Luis R. Rodriguez
2008-12-02 20:51     ` [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully Luis R. Rodriguez
2008-12-03  0:12       ` [stable] " Greg KH
2008-12-03  0:20         ` Luis R. Rodriguez
2008-12-03  0:24           ` John W. Linville
2008-12-03 20:19             ` [ath9k-devel] " Luis R. Rodriguez
2008-12-03 20:32               ` Greg KH
2008-12-03 21:22             ` John W. Linville
2008-12-03 22:14               ` [ath9k-devel] " Luis R. Rodriguez
2008-12-02 20:57 ` [ath9k-devel] [PATCH 0/3] ath9k: several fixes ported to 2.6.27 Luis R. Rodriguez
2008-12-02 21:27 ` [stable] " Greg KH
2008-12-02 22:13   ` Luis R. Rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1228251082-11677-2-git-send-email-lrodriguez@atheros.com \
    --to=lrodriguez@atheros.com \
    --cc=Bennyam.Malavazi@atheros.com \
    --cc=ath9k-devel@venema.h4ckr.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=stable@kernel.org \
    --cc=zenczykowski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®