Re: ath10k + INTEL_IDLE aka. cstates == firmware crash

[Fabian Wittenberg <Fabian.Wittenberg@sophos.com>]

Hi Michal,

I already did this approach. This works fine and is the current
workaround to get the product out, but I would like to know what the
basic problem is.
The power consumption increases by ~1.25W on idle devices if you disable
cstates. This is not a real problem but a low mem corruption is one.
So I assume a bug in the ath10k-driver/firmware.

Regards,
Fabian

Am 23.02.2015 um 15:20 schrieb Michal Kazior:
> On 23 February 2015 at 14:44, Fabian Wittenberg
> <Fabian.Wittenberg@sophos.com> wrote:
>> Hi Michal,
>>
>> I used firmware version 10.1 and 10.2 from here:
>> https://github.com/kvalo/ath10k-firmware. Both show the same behavior.
>>
>> You are right. There are some BIOS that do strange handling of this
>> cstate stuff but we have no influence on the BIOS as this is done by
>> our hardware vendor. We experimented a lot with the MSI masking bit of
>> the pci-e root bridge where the ac-card is connected to.
>> There were no remarkable improvements playing around with this bit.
> If you don't have BIOS/UEFI upgrade available you can try appending
> `intel_idle.max_cstate=0` to kernel boot parameters. Keep in mind this
> will disable CPU power management.
>
>
>> We have tested the same boards with cards that need ath9k as well. They
>> are working just fine. With and without enabled INTEL_IDLE...
> I run with my laptops (i5-3320M and  i5-2520M) with INTEL_IDLE and QCA988x fine.
>
> I'm not really an expert on this stuff but since C-state alter some
> voltages perhaps the Atom SoC has some deviations/instabilities in
> voltages which prevent some quirky devices like QCA988x from working
> reliably.
>
>
> Michał


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