Wmi command WMI_FORCE_FW_HANG_CMDID is not supported
in firmware 10.1. In order to have firmware crash simulation
functionality also in firmware 10.1 driver can force firmware
crash by performing not allowed operation. Driver can deliberately
crash firmware when setting vdev param for vdev id out of range.
Command to trigger firmware crash:
echo "crash" > /sys/kernel/debug/ieee80211/phyX/ath10k/simulate_fw_crash
Signed-off-by: Marek Puzyniak <[email protected]>
---
drivers/net/wireless/ath/ath10k/debug.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 6debd28..84b79c5 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -482,11 +482,23 @@ static ssize_t ath10k_write_simulate_fw_crash(struct file *file,
ath10k_info("simulating firmware crash\n");
ret = ath10k_wmi_force_fw_hang(ar, WMI_FORCE_FW_HANG_ASSERT, 0);
- if (ret)
+ if (ret == 0) {
+ ret = count;
+ goto exit;
+ }
+
+ if (ret != -EOPNOTSUPP) {
ath10k_warn("failed to force fw hang (%d)\n", ret);
+ goto exit;
+ }
- if (ret == 0)
- ret = count;
+ /*
+ * Firmware does not support WMI_FORCE_FW_HANG_ASSERT.
+ * Force firmware crash by setting any vdev parameter for
+ * not allowed vdev id.
+ */
+ ath10k_wmi_vdev_set_param(ar, TARGET_NUM_VDEVS + 1,
+ ar->wmi.vdev_param->rts_threshold, 0);
exit:
mutex_unlock(&ar->conf_mutex);
--
1.8.1.2
Michal Kazior <[email protected]> writes:
> On 10 February 2014 18:13, Marek Puzyniak <[email protected]> wrote:
>> Wmi command WMI_FORCE_FW_HANG_CMDID is not supported
>> in firmware 10.1. In order to have firmware crash simulation
>> functionality also in firmware 10.1 driver can force firmware
>> crash by performing not allowed operation. Driver can deliberately
>> crash firmware when setting vdev param for vdev id out of range.
>>
>> Command to trigger firmware crash:
>> echo "crash" > /sys/kernel/debug/ieee80211/phyX/ath10k/simulate_fw_crash
>>
>> Signed-off-by: Marek Puzyniak <[email protected]>
>> ---
>
> The 'fw hang assert' crash can be recovered with a warm reset but a
> real crash can't.
Oh, I didn't know that.
> Thus, I think the two crash methods should be distinguishable
Yeah, I agree.
> by having either two separate debugfs files or two separate trigger
> keywords.
I think having a keyword would be a better to way differentiate these.
And if the firmware doesn't support WMI_FORCE_FW_HANG_ASSERT, then just
return -EOPNOTSUPP.
--
Kalle Valo
On 10 February 2014 18:13, Marek Puzyniak <[email protected]> wrote:
> Wmi command WMI_FORCE_FW_HANG_CMDID is not supported
> in firmware 10.1. In order to have firmware crash simulation
> functionality also in firmware 10.1 driver can force firmware
> crash by performing not allowed operation. Driver can deliberately
> crash firmware when setting vdev param for vdev id out of range.
>
> Command to trigger firmware crash:
> echo "crash" > /sys/kernel/debug/ieee80211/phyX/ath10k/simulate_fw_crash
>
> Signed-off-by: Marek Puzyniak <[email protected]>
> ---
The 'fw hang assert' crash can be recovered with a warm reset but a
real crash can't. Thus, I think the two crash methods should be
distinguishable by having either two separate debugfs files or two
separate trigger keywords.
Michał
On 13 February 2014 15:52, Kalle Valo <[email protected]> wrote:
> Michal Kazior <[email protected]> writes:
>
>> On 10 February 2014 18:13, Marek Puzyniak <[email protected]> wrote:
>>> Wmi command WMI_FORCE_FW_HANG_CMDID is not supported
>>> in firmware 10.1. In order to have firmware crash simulation
>>> functionality also in firmware 10.1 driver can force firmware
>>> crash by performing not allowed operation. Driver can deliberately
>>> crash firmware when setting vdev param for vdev id out of range.
>>>
>>> Command to trigger firmware crash:
>>> echo "crash" > /sys/kernel/debug/ieee80211/phyX/ath10k/simulate_fw_crash
>>>
>>> Signed-off-by: Marek Puzyniak <[email protected]>
>>> ---
>>
>> The 'fw hang assert' crash can be recovered with a warm reset but a
>> real crash can't.
>
> Oh, I didn't know that.
>
>> Thus, I think the two crash methods should be distinguishable
>
> Yeah, I agree.
>
>> by having either two separate debugfs files or two separate trigger
>> keywords.
>
> I think having a keyword would be a better to way differentiate these.
> And if the firmware doesn't support WMI_FORCE_FW_HANG_ASSERT, then just
> return -EOPNOTSUPP.
I will send new version with different keyword for different kind of
firmware crash.
Marek