On 02/08/2015 10:24 PM, Michal Kazior wrote:
On 6 February 2015 at 17:15, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
On 02/06/2015 04:05 AM, Michal Kazior wrote:
It makes little sense to continue and let
firmware-host state become inconsistent if a WMI
command can't be submitted to firmware.
This effectively prevents after-affects of
tx-credit starvation bug which include spurious
sta kickout events and inability to associate new
stations after some time when acting as AP.
This should also speed up recovery/teardown in
some cases when firmware stops responding for some
reason.
I have not seen a WMI timeout since I added keep-alive
and CE polling in my firmware, but the patch looks OK
to me.
This is mainly aimed at the tx-credit starvation due to mgmt-tx being
stuck on client powersave buffering.
You might add something about 'WMI' in that warning
message to make it more clear what is not being
responsive.
Good point.
At least in my tests, I could continue
to receive network traffic while WMI was blocked.
Yeah. Traffic works with the tx-credit starvation as well but what
good is this if you have inconsistent driver-firmware state after
failing to send a few commands?
I just mention it because someone debugging the system might
wonder why the firmware is 'locked up' while it is still passing traffic.
I agree with your patch in general.
If it is just powersave issue, could you force (overriding wmi tx-credits limit)
a flush at the 1 second mark and hope it recovers by 3 second timeout?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
