ath10k driver crashes whenever firmware crashes on ARM SoC

Kalle Valo kvalo at
Tue Mar 11 03:33:46 EDT 2014

Avery Pennarun <apenwarr at> writes:

> On Wed, Jan 29, 2014 at 9:41 PM, Avery Pennarun <apenwarr at> wrote:
>> Still chasing around some people to get a PCIe bus analyzer set up.
> Okay, I finally managed to get enough parts put together to look at
> the PCIe bus.  To make things a little more clear, I added a macro
> that does essentially:
>    pci_write_config_dword(0, 0x80000000 | __LINE__)
>    mdelay(1);
>    pci_write_config_dword(0, __LINE__)
> various points in the code.  This way I can see precisely what
> was the most recent PCIe transaction before the crash.
> I'm not super familiar with PCIe, but what I think I'm seeing is:
> - the firmware does not need to be loaded yet; sometimes I can crash
> it just by doing a cold reset right at driver load time.  So the good
> news is, the firmware code is not related.
> - the crash is always in ath10k_pci_device_reset


> Does this ring a bell for anyone?  I think I can also export the
> traces as csv in case someone wants to look at them.

I showed your analysis to an HW engineer and the response I got was
"don't do that" (= don't use the cold reset). As you know, we now have a
workaround using the warm reset:

00f5482bcd94 ath10k: suspend hardware before reset
9042e17df834 ath10k: refactor suspend/resume functions
fc36e3ffcdd0 ath10k: fix device initialization routine

Have you tested these? Did they help at all?

Kalle Valo

More information about the ath10k mailing list