Failed to wake device (9984)

Adrian Chadd adrian at
Fri Sep 15 12:38:45 PDT 2017

On 15 September 2017 at 09:59, Ben Greear <greearb at> wrote:
> On 09/14/2017 07:33 PM, Adrian Chadd wrote:
>> On 14 September 2017 at 17:13, Ben Greear <greearb at> wrote:
>>>> There were always weird cold reset races that necessitated a PCI bus
>>>> reset of the device. :( can you even see the device? do any of the registers
>>>> work?
>>> Can the cold reset be done on generic x86-64 hardware?
>> I'll have to go check. You /should/ be able to. Are there are power
>> and reset files in /sys/bus/pci for those devices?
>>> And, it shows up enough that the system probes it, at least.  I guess no
>>> infrastructure to speak of set up for this thing, so not sure how to
>>> probe any registers.
>> Well, that could be cached BAR information. There are some cold / warm
>> reset registers in the RTC block that are used during initial wakeup;
>> print what they're saying to see if it's coming back 0xfffffff or
>> 0xdeadc0de or something?
> One thing I notice, if I simply:  rmmod ath10k_pci ath10k_core; modprobe
> ath10k_pci
> then it recovered (1 of 1 so far).

See if that's reliable. For QCA9880 I know it needed a full
reacharound sometimes (ie, the reference driver has hooks to reach
back into the PCIe nexus to toggle reset.)

> We'll see if that is a reliable way to recover from this problem.  And, will
> see if we
> can also find a nicer way to go about it...maybe there is just a timer that
> is not long
> enough somewhere?

It's possible. I am just always wary about their host glue in the chip
:-) If reloading the driver helps then great. But all that /should/ be
dong is a cold reset / wakeup..


More information about the ath10k mailing list