On 9 February 2015 at 17:03, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > On 02/08/2015 10:24 PM, Michal Kazior wrote: >> On 6 February 2015 at 17:15, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: [...] >>> 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 might as well include this info in the commit log. > 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? Well, there's a couple of problems with that. 1) you suggest to call wmi_flush() which calls wmi_cmd_send() *while* in wmi_cmd_send(), 2) you're out of credits, how do you intend to submit a frame, 3) yes, you can force it, but that's super ugly, 4) and this still doesn't guarantee you'll get your tx-credit due to firmware quirkiness. (but maybe the latest 10.2.4 behaves differently? who knows..) My original stab at this involved a proactive flushing but it had it's problems (delayed mgmt frames, could still get stuck in rare cases). Michał -- 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
