Failed to wake device (9984)
Adrian Chadd
adrian at freebsd.org
Fri Sep 15 12:38:45 PDT 2017
On 15 September 2017 at 09:59, Ben Greear <greearb at candelatech.com> wrote:
> On 09/14/2017 07:33 PM, Adrian Chadd wrote:
>>
>> On 14 September 2017 at 17:13, Ben Greear <greearb at candelatech.com> 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..
-adrian
More information about the ath10k
mailing list