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

[Ben Greear <greearb@candelatech.com>]

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

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
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k