From: reinette chatre <reinette.chatre@intel.com>
To: Jason Andryuk <jandryuk@gmail.com>
Cc: "Kolekar, Abhijeet" <abhijeet.kolekar@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: Fri, 27 Mar 2009 09:28:16 -0700 [thread overview]
Message-ID: <1238171296.25568.21.camel@rc-desk> (raw)
In-Reply-To: <1237768621.8764.13.camel@rainbow>
Hi Jason,
I thought you may want to hear an update since it is almost a week since
your last message ...
Thanks to your digging I was able to reproduce the SYSASSERT and find
the issues you discovered through your analysis. I am working on a
different solution that has tx buffers working again. I am still
scratching my head with a rx buffer issue and will send out a patch as
soon as that is resolved.
More below ...
On Sun, 2009-03-22 at 17:37 -0700, Jason Andryuk wrote:
> 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 don't think this is necessary ... we should just take care to have
data complete before handing it to device. In the iwlagn driver we have
to do this because the command actually contains the dma address ... so
we first need to map the data, get the address, take buffer back, and
then be able to update command with that address ...
> 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.
I did something similar and it seems to work ...
> 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.
I think this is necessary, and I also do something similar in my patch.
The problem here is that the meta data in the command contains the bus
address. If we map that to the device then it introduces a problem ...
at the time we need to unmap the data we need to access the address in
the mapped data. We should thus only map the data starting from the
header.
> 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.
yup ... but this does cause a problem at unmap time.
>
> 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.
>
... but which address to give this function? Rather just not map it in
the first place. This should be possible.
I hope to have a patch for you soon.
Reinette
next prev parent reply other threads:[~2009-03-27 16:22 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
2009-03-27 16:28 ` reinette chatre [this message]
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=1238171296.25568.21.camel@rc-desk \
--to=reinette.chatre@intel.com \
--cc=abhijeet.kolekar@intel.com \
--cc=jandryuk@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--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).