On 15 September 2017 at 09:59, Ben Greear <[email protected]> wrote: > On 09/14/2017 07:33 PM, Adrian Chadd wrote: >> >> On 14 September 2017 at 17:13, Ben Greear <[email protected]> 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 _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
