From: David Mosberger <davidm@napali.hpl.hp.com>
To: "David S. Miller" <davem@redhat.com>
Cc: linux-kernel@vger.kernel.org, davidm@napali.hpl.hp.com
Subject: Re: problem with blk_queue_bounce_limit()
Date: Tue, 10 Jun 2003 13:01:29 -0700 [thread overview]
Message-ID: <16102.14617.25302.441894@napali.hpl.hp.com> (raw)
In-Reply-To: <20030607.001140.08328499.davem@redhat.com>
>>>>> On Sat, 07 Jun 2003 00:11:40 -0700 (PDT), "David S. Miller" <davem@redhat.com> said:
>> From: David Mosberger <davidm@napali.hpl.hp.com> Date: Sat, 7
>> Jun 2003 00:05:06 -0700
>> Isn't the proper fix to (a) get a new buffer, (b) create a
>> mapping for the new buffer, (c) destroy the mapping for the old
>> buffer. That should guarantee a different bus address, no matter
>> what the DMA-mapping implementation.
> I suppose this would work, fell free to code this up for the tg3
> driver for me because I certainly lack the time to do this.
How about the attached patch?
The non-PCI_DMA_BUS_IS_PHYS code should work already, because it
creates the new mapping before destroying the old one(s).
The patch has been compiled-tested but not runtime-tested: I can't
trigger the bug on ia64, because there, the end of the 4GB space is
reserved for firmware purposes, so we'll never have available memory
near address 0xffffdcc0.
The performance impact should be negligible, as the probability of
hitting the bug case should be vanishingly small.
--david
===== drivers/net/tg3.c 1.68 vs edited =====
--- 1.68/drivers/net/tg3.c Wed Apr 23 20:02:11 2003
+++ edited/drivers/net/tg3.c Tue Jun 10 12:53:15 2003
@@ -2234,73 +2234,17 @@
schedule_work(&tp->reset_task);
}
-#if !PCI_DMA_BUS_IS_PHYS
-static void tg3_set_txd_addr(struct tg3 *tp, int entry, dma_addr_t mapping)
-{
- if (tp->tg3_flags & TG3_FLAG_HOST_TXDS) {
- struct tg3_tx_buffer_desc *txd = &tp->tx_ring[entry];
-
- txd->addr_hi = ((u64) mapping >> 32);
- txd->addr_lo = ((u64) mapping & 0xffffffff);
- } else {
- unsigned long txd;
-
- txd = (tp->regs +
- NIC_SRAM_WIN_BASE +
- NIC_SRAM_TX_BUFFER_DESC);
- txd += (entry * TXD_SIZE);
-
- if (sizeof(dma_addr_t) != sizeof(u32))
- writel(((u64) mapping >> 32),
- txd + TXD_ADDR + TG3_64BIT_REG_HIGH);
-
- writel(((u64) mapping & 0xffffffff),
- txd + TXD_ADDR + TG3_64BIT_REG_LOW);
- }
-}
-#endif
-
static void tg3_set_txd(struct tg3 *, int, dma_addr_t, int, u32, u32);
static int tigon3_4gb_hwbug_workaround(struct tg3 *tp, struct sk_buff *skb,
u32 guilty_entry, int guilty_len,
u32 last_plus_one, u32 *start, u32 mss)
{
+ struct sk_buff *new_skb = skb_copy(skb, GFP_ATOMIC);
dma_addr_t new_addr;
u32 entry = *start;
int i;
-#if !PCI_DMA_BUS_IS_PHYS
- /* IOMMU, just map the guilty area again which is guaranteed to
- * use different addresses.
- */
-
- i = 0;
- while (entry != guilty_entry) {
- entry = NEXT_TX(entry);
- i++;
- }
- if (i == 0) {
- new_addr = pci_map_single(tp->pdev, skb->data, guilty_len,
- PCI_DMA_TODEVICE);
- } else {
- skb_frag_t *frag = &skb_shinfo(skb)->frags[i - 1];
-
- new_addr = pci_map_page(tp->pdev,
- frag->page, frag->page_offset,
- guilty_len, PCI_DMA_TODEVICE);
- }
- pci_unmap_single(tp->pdev, pci_unmap_addr(&tp->tx_buffers[guilty_entry],
- mapping),
- guilty_len, PCI_DMA_TODEVICE);
- tg3_set_txd_addr(tp, guilty_entry, new_addr);
- pci_unmap_addr_set(&tp->tx_buffers[guilty_entry], mapping,
- new_addr);
- *start = last_plus_one;
-#else
- /* Oh well, no IOMMU, have to allocate a whole new SKB. */
- struct sk_buff *new_skb = skb_copy(skb, GFP_ATOMIC);
-
if (!new_skb) {
dev_kfree_skb(skb);
return -1;
@@ -2337,7 +2281,6 @@
}
dev_kfree_skb(skb);
-#endif
return 0;
}
next prev parent reply other threads:[~2003-06-10 19:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-05 6:42 David Mosberger
2003-06-05 7:20 ` David S. Miller
2003-06-06 6:42 ` David Mosberger
2003-06-06 6:45 ` David S. Miller
2003-06-06 6:54 ` David Mosberger
2003-06-06 7:08 ` David S. Miller
2003-06-06 6:52 ` David S. Miller
2003-06-06 7:19 ` David Mosberger
2003-06-06 7:32 ` David S. Miller
2003-06-06 7:44 ` Christoph Hellwig
2003-06-06 7:43 ` David S. Miller
2003-06-06 7:51 ` Christoph Hellwig
2003-06-06 20:13 ` David Mosberger
2003-06-07 6:44 ` David S. Miller
2003-06-07 7:05 ` David Mosberger
2003-06-07 7:11 ` David S. Miller
2003-06-10 20:01 ` David Mosberger [this message]
2003-06-12 6:47 ` David S. Miller
2003-06-15 7:06 ` Anton Blanchard
2003-06-15 7:11 ` David S. Miller
2003-06-15 8:04 ` Anton Blanchard
2003-06-15 8:18 ` David S. Miller
2003-06-07 7:20 ` David Mosberger
2003-06-07 7:19 ` David S. Miller
2003-06-07 9:44 ` Russell King
2003-06-07 9:47 ` David S. Miller
2003-06-07 13:23 ` Christoph Hellwig
2003-06-10 20:24 ` David Mosberger
2003-06-06 18:06 James Bottomley
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=16102.14617.25302.441894@napali.hpl.hp.com \
--to=davidm@napali.hpl.hp.com \
--cc=davem@redhat.com \
--cc=davidm@hpl.hp.com \
--cc=linux-kernel@vger.kernel.org \
/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®