ath10k driver crashes whenever firmware crashes on ARM SoC

Adrian Chadd adrian at
Thu Mar 13 13:34:26 EDT 2014

I think the CUS223 has higher transmit power, right?


On 12 March 2014 22:09, Kalle Valo <kvalo at> wrote:
> Avery Pennarun <apenwarr at> writes:
>> On Wed, Mar 12, 2014 at 11:01 AM, Ben Greear <greearb at> wrote:
>>> Come to think of it, I'm not sure I've seen a hard lockup of the machine
>>> on non CUS223 machines, but I have seen cases where non CUS223 NIC wedges
>>> and the existing restart does not recover it.
>>> This requires a reboot to recover from.
>> That's not so surprising; the current driver doesn't do the cold reset
>> that is the only thing you can recover from a wedge, I guess because
>> of the CUS223 bug.
>> Stupid question: can I honestly just buy a different module and make
>> my PCIe crashiness problems go away?
> That's my theory, but I would like to confirm that somehow.
>> Is there a reason do prefer the CUS223?
> Good question, I haven't figured out that. CUS223 board is physically
> larger than XB140, for example, and I would assume there's a reason for
> that.
>> Another question: is there perhaps anything the firmware can do to eg.
>> set a watchdog timer, so that the internal CPU will restart (go back
>> to "waiting for firmware" mode) if it doesn't answer for a while?  The
>> idea would be for the device to un-wedge itself even if there's
>> nothing we can do to fix it from outside.
> That's something a firmware engineer should comment on, which I'm not.
> --
> Kalle Valo

More information about the ath10k mailing list