ath10k driver crashes whenever firmware crashes on ARM SoC

[Kalle Valo]

Avery Pennarun <apenwarr at gmail.com> writes:

> On Wed, Mar 12, 2014 at 11:01 AM, Ben Greear <greearb at candelatech.com> 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