ath10k driver crashes whenever firmware crashes on ARM SoC

[Adrian Chadd]

I think the CUS223 has higher transmit power, right?


-a


On 12 March 2014 22:09, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> 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