[PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform

[Adrian Chadd]

On 19 July 2016 at 08:25, Manoharan, Rajkumar <rmanohar at qti.qualcomm.com> wrote:
> On June 30, 2016 12:39 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
>> On 29 June 2016 at 18:35, Manoharan, Rajkumar <rmanohar at qti.qualcomm.com> 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.



-adrian