ath10k + INTEL_IDLE aka. cstates == firmware crash

[Fabian Wittenberg]

Today we encountered a similar issue on a QCA9558 as well.
However its really rare to see it on this chipset.
This is a SoC with MIPS architecture. Widely used on access points.
I really think you could be right with your quess.
But that should be a QCA task as its really related to their h/w.
We are using backports/ath10k for the PCI card and the SoC.

Regards,
Fabian

Am 19.03.2015 um 17:05 schrieb Adrian Chadd:
> On 19 March 2015 at 08:57, Fabian Wittenberg
> <Fabian.Wittenberg at sophos.com> wrote:
>> Yes, I guessed something like that but this should be a firmwarebug :-\
>> I'm quiet surprized that nowbody else has this problem!?
>> There are so many configuration constellations that trigger this...
> The sleep depth / time that a socket-sleep state can take to wakeup to
> do DMA is highly variable. It's based on chipset, BIOS and sleep
> settings.
>
> IIRC the ath10k firmware wasn't really debugged with hostap-on-intel
> as a supported option, with all the varying things there. So yeah,
> someone with more detailed DMA/PCIe bridge documentation for QCA988x
> is going to have to dig into the DMA register settings to see what's
> going on. Maybe it's just exceeding the transaction timeout and that
> should be easy to fix.
>
> (I currently don't have all of the register documentation for the
> QCA988x as I do for the pre-11ac chips.)
>
>
> adrian
>
>> Fabian
>>
>> Am 19.03.2015 um 16:44 schrieb Adrian Chadd:
>>> It's possible that you're entering a sleep state, the whole socket +
>>> dram controller is going to sleep, and the latency that the wakeup
>>> causes is confusing the firmware and/or DMA engine.
>>>
>>>
>>>
>>> -adrian
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k