All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabian Wittenberg <Fabian.Wittenberg@sophos.com>
To: Adrian Chadd <adrian@freebsd.org>
Cc: Michal Kazior <michal.kazior@tieto.com>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: ath10k + INTEL_IDLE aka. cstates == firmware crash
Date: Fri, 20 Mar 2015 11:46:46 +0100	[thread overview]
Message-ID: <550BFA96.3030105@sophos.com> (raw)
In-Reply-To: <CAJ-Vmo=UEQ+MjZ+tgq9=ED5ca3f=Jb+9iBbs2LDN6zLsEPO94Q@mail.gmail.com>

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



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

  parent reply	other threads:[~2015-03-20 10:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-23 13:08 ath10k + INTEL_IDLE aka. cstates == firmware crash Fabian Wittenberg
2015-02-23 13:32 ` Michal Kazior
2015-02-23 13:44   ` Fabian Wittenberg
2015-02-23 14:20     ` Michal Kazior
2015-02-23 14:41       ` Fabian Wittenberg
2015-03-02 12:20         ` Michal Kazior
2015-03-19  9:20           ` Fabian Wittenberg
2015-03-19 15:44             ` Adrian Chadd
2015-03-19 15:57               ` Fabian Wittenberg
2015-03-19 16:05                 ` Adrian Chadd
2015-03-19 16:18                   ` Fabian Wittenberg
2015-03-19 16:23                     ` Adrian Chadd
2015-03-20 10:46                   ` Fabian Wittenberg [this message]
2015-02-23 16:58 ` Ben Greear
2015-03-08 13:45 ` Jeremias Blendin
2015-03-08 18:27   ` Ben Greear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550BFA96.3030105@sophos.com \
    --to=fabian.wittenberg@sophos.com \
    --cc=adrian@freebsd.org \
    --cc=ath10k@lists.infradead.org \
    --cc=michal.kazior@tieto.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.