From: Jason Andryuk <jandryuk@gmail.com>
To: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Cc: "Chatre, Reinette" <reinette.chatre@intel.com>,
Samuel Ortiz <samuel@sortiz.org>,
Tomas Winkler <tomasw@gmail.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: kernel BUG at drivers/net/wireless/iwlwifi/iwl3945-base.c:3127!
Date: Sun, 22 Mar 2009 20:37:01 -0400 [thread overview]
Message-ID: <1237768621.8764.13.camel@rainbow> (raw)
In-Reply-To: <c4d76b3b0903221029r21282bbbs13a8af06f9d8ce2@mail.gmail.com>
On Sun, 2009-03-22 at 13:29 -0400, Jason Andryuk wrote:
> The patch did not work.
>
> However, I do not think it's an alignment issue.
>
> pci_map_single on x86_64 with >3G memory and no IOMMU uses the swiotlb
> by default. swiotlb provides "bounce buffers" for physical addresses
> over 4GB. So for memory where the kmalloc value is at a physical
> address over 2**32, pci_map_single will copy to a swiotlb slot. That
> means the dma_handle return value of pci_map_single is not necessarily
> the physical address of the virtual address.
>
> In iwl3945_tx_skb (iwl3945-base.c line 1099) use the pci_map_single
> which copies the memory of out_cmd at that time. However,
> iwl3945_build_tx_cmd_basic, iwl3945_hw_build_tx_cmd_rate, and
> iwl3945_build_tx_cmd_hwcrypto are all passed out_cmd and modify memory
> located there. These modifications are not reflected in the memory
> located at txcmd_phys.
>
> pci_map_single should only be called once the tx command structures
> are completely written.
>
> Additionally, pci_unmap_single should be called once the memory is no
> longer needed to free the swiotlb entry for that command. I am not
> sure if this is currently handled for all cases.
>
> Previous use of pci_alloc_coherent meant that memory would allocated
> at an physical address below 4GB and kept in-sync both the device and
> cpu.
>
> Refer to Documentation/x86/x86_64/boot-options.txt and lib/swiotlb.c
> for information on IOMMU and swiotlb
>
> Jason
I hacked up an inelegant patch that does get the driver working.
We call pci_dma_sync_single_for_device to ensure the correct contents
are visible to the device. That is, we copy out_cmd to phys_addr, so
the desired contents are viewable for the device.
I tried moving the pci_map_single call to right before the call to
iwl_txq_update_write_ptr, but I never got that working successfully.
Presumably that is how the problem should be fixed. Another failed
attempt was to map from "out_cmd + offsetof(struck iwl_cmd, hdr)"
instead of out_cmd. The phys_addr + offsetof(struck iwl_cmd, hdr) is
what is passed to txq_attach_buf_to_tfd, so I thought that should work.
Unfortunately it did not. The added benefit would have been that it
moved "len" and "mapping" of struct iwl_cmd_meta out of the mapped area.
Then losing them since they were written after the mapping would not
have been a problem.
If struct iwl_cmd_meta's len and mapping members are read by one of the
"reclaim" functions, then they should probably be sync'ed with
pci_dma_sync_single_for_cpu beforehand.
Jason
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index b13862a..8ec26c7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -975,6 +975,9 @@ int iwl_enqueue_hcmd(struct iwl_priv *priv, struct iwl_host_cmd *cmd)
pci_unmap_len_set(&out_cmd->meta, len, len);
phys_addr += offsetof(struct iwl_cmd, hdr);
+ pci_dma_sync_single_for_device(priv->pci_dev, phys_addr,
+ len, PCI_DMA_BIDIRECTIONAL);
+
priv->cfg->ops->lib->txq_attach_buf_to_tfd(priv, txq,
phys_addr, fix_size, 1,
U32_PAD(cmd->len));
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 279d10c..a32ee4e 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -1151,6 +1151,12 @@ static int iwl3945_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
iwl_print_hex_dump(priv, IWL_DL_TX, (u8 *)tx->hdr,
ieee80211_hdrlen(fc));
+ pci_dma_sync_single_for_device(priv->pci_dev,
+ txcmd_phys, sizeof(struct iwl_cmd),
+ PCI_DMA_TODEVICE);
+ pci_dma_sync_single_for_device(priv->pci_dev, phys_addr,
+ skb->len - hdr_len,
+ PCI_DMA_TODEVICE);
/* Tell device the write index *just past* this latest filled TFD */
q->write_ptr = iwl_queue_inc_wrap(q->write_ptr, q->n_bd);
rc = iwl_txq_update_write_ptr(priv, txq);
next prev parent reply other threads:[~2009-03-23 0:37 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-18 0:06 kernel BUG at drivers/net/wireless/iwlwifi/iwl3945-base.c:3127! Deuce
2009-01-18 17:41 ` Deuce
2009-01-26 11:44 ` Samuel Ortiz
2009-01-27 3:13 ` Jason Andryuk
2009-01-27 3:35 ` Jason Andryuk
2009-01-27 16:24 ` Samuel Ortiz
2009-01-27 23:31 ` Jason Andryuk
2009-01-28 7:12 ` Tomas Winkler
2009-01-28 11:37 ` Samuel Ortiz
2009-01-28 11:52 ` Tomas Winkler
2009-01-28 12:12 ` Samuel Ortiz
2009-02-20 4:17 ` Jason Andryuk
2009-02-20 19:49 ` reinette chatre
2009-02-23 0:10 ` Jason Andryuk
2009-02-23 4:37 ` Jason Andryuk
2009-02-23 19:21 ` reinette chatre
2009-02-23 22:28 ` reinette chatre
2009-02-24 3:02 ` Jason Andryuk
2009-02-24 0:15 ` reinette chatre
2009-02-24 2:47 ` Jason Andryuk
2009-03-02 3:37 ` Jason Andryuk
2009-03-04 4:32 ` Jason Andryuk
2009-03-04 19:19 ` reinette chatre
2009-03-04 19:47 ` Jason Andryuk
2009-03-05 0:04 ` reinette chatre
2009-03-05 23:50 ` Jason Andryuk
2009-03-06 0:24 ` reinette chatre
2009-03-06 4:12 ` Jason Andryuk
2009-03-06 5:39 ` reinette chatre
2009-03-10 1:40 ` Jason Andryuk
2009-03-10 3:32 ` Jason Andryuk
2009-03-10 5:04 ` reinette chatre
2009-03-10 13:10 ` Jason Andryuk
2009-03-10 18:22 ` Abhijeet Kolekar
2009-03-11 3:11 ` Jason Andryuk
2009-03-11 2:57 ` Jason Andryuk
2009-03-11 3:40 ` Jason Andryuk
2009-03-13 3:31 ` Jason Andryuk
2009-03-16 12:10 ` Jason Andryuk
2009-03-17 1:44 ` Jason Andryuk
2009-03-19 1:52 ` Jason Andryuk
2009-03-20 1:22 ` Jason Andryuk
2009-03-20 20:39 ` Abhijeet Kolekar
2009-03-22 17:29 ` Jason Andryuk
2009-03-23 0:37 ` Jason Andryuk [this message]
2009-03-27 16:28 ` reinette chatre
2009-03-31 22:22 ` reinette chatre
2009-04-01 1:28 ` Jason Andryuk
2009-04-21 1:41 ` Jason Andryuk
2009-04-21 15:42 ` reinette chatre
-- strict thread matches above, loose matches on Subject: below --
2009-01-09 3:28 Deuce
2009-01-09 19:12 ` reinette chatre
2009-01-09 23:07 ` Deuce
2009-01-12 18:38 ` Samuel Ortiz
2009-01-13 3:12 ` Deuce
2009-01-13 4:37 ` Deuce
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=1237768621.8764.13.camel@rainbow \
--to=jandryuk@gmail.com \
--cc=abhijeet.kolekar@intel.com \
--cc=linux-wireless@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=samuel@sortiz.org \
--cc=tomasw@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;
as well as URLs for NNTP newsgroup(s).