On 07/19/2016 09:13 AM, Adrian Chadd wrote:
On 19 July 2016 at 08:25, Manoharan, Rajkumar <[email protected]> wrote:
On June 30, 2016 12:39 PM, Michal Kazior <[email protected]> wrote:
On 29 June 2016 at 18:35, Manoharan, Rajkumar <[email protected]> wrote:
Am 29.06.2016 um 16:04 schrieb Sebastian Gottschall:
this fix will crash QCA9980 on QCA IPQ8064 cpu based systems.
so please rework it, or leave it out.
note:
maybe the limit of 256kb is too low for that card
by the way. 512 works
I think this suggests the problem isn't about memory chunk size limit
per se but some kind of bug in address/offset logic in fw or hw.
DMA coherent and single-map addresses use completely different ranges
in many cases. Perhaps some MSBs are not properly handled in fw or hw.
I recall there is a magic macro through which target device accesses
host memory so maybe that's a good place to look to better understand
the problem?
Michał,
Could you please shed some light on this issue? It seems this issue is popping
up
more frequently and there are multiple threads for this issue.
"Anyone brought up 9984 NIC on x86-64?"
"AR9882 IOMMU faults"
I recall Ben mentioned he worked around the problem by enabling
IOMMU/VT-d on his system. This could either prevent the device from
doing bad things or maybe changed DMA address ranges that are handed
out to the driver effectively or changed PCI controller behavior in
some way.
Thanks a lot Sebastian. Let me confirm the same on x86 and will update the
change.
Just changing the memory chunk size limit blindly is bad and
Sebastian's crash has proven it. 512 may seem to work now but it may
fail with a other 10.4 firmware revisions or make x86 hang in other
cases.
Even with current logic, If the memory chunk allocation fails for bigger size,
then it tries
to allocate smaller chunks. So If smaller chunks causes unexpected behaviour,
it is even
applicable to existing logic. no?
Try allocating WMI memory with GFP_DMA32. The way it currently is
working in linux is that caling dma map ends up allocating iommu slots
to map that 64 bit memory back into 32 bit space, /or/ it will end up
allocating bounce buffers.
The WMI memory alloc routine is being used for the swap space too,
which ends up with 700kbyte or more allocated twice - once for the
initial alloc, and another for the dma map call.
You should try GFP_DMA32 and see if that fixes it. You need contig, <
32 bit physical memory allocated, and bounce buffers are really
supposed to be ephemeral.
I briefly tested with the GFP_DMA32 and it worked on my 9984 test rig.
I also found firmware bugs in my 10.4.3 (3.3-25) based firmware when smaller
chunk sizes are used. Possibly this is fixed in QCA firmware images, but likely
if you select more active peers than will fit in one 256k chunk your firmware
will crash. I tested with 72 active peers. I have fixed this bug in my 9984
firmware
as far as I can tell, but I have not run stress tests on it yet.
Thanks,
Ben
-adrian
_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k
