On 26 March 2014 15:40, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > On 03/26/2014 12:18 AM, Michal Kazior wrote: >> >> On 25 March 2014 16:14, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: >>> >>> On 03/25/2014 12:27 AM, Michal Kazior wrote: >>>> >>>> >>>> On 24 March 2014 17:50, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: >>>>> >>>>> >>>>> On 03/24/2014 04:21 AM, Michal Kazior wrote: >>>>>> >>>>>> >>>>>> On 24 March 2014 12:12, Kalle Valo <kvalo@xxxxxxxxxxxxxxxx> wrote: >>>>> >>>>> >>>>> >>>>>>>> - status = ath10k_htc_send(htc, ATH10K_HTC_EP_0, skb); >>>>>>>> + status = ath10k_htc_send(htc, ATH10K_HTC_EP_0, skb, __LINE__); >>>>>>> >>>>>>> >>>>>>> >>>>>>> Using line numbers in debug messages is very cumbersome. Some people >>>>>>> cherry pick patches, have their own changes and whatnot which will >>>>>>> make >>>>>>> it more difficult to read the debug logs. Isn't there any better way >>>>>>> to >>>>>>> do this? >>>>>> >>>>>> >>>>>> >>>>>> I would prefer to explicitly wait for tx credit replenishment in >>>>>> ath10k_wmi_cmd_send() after a command is sent instead of all these >>>>>> prints. This way you can get a full call trace if it times out. >>>>> >>>>> >>>>> >>>>> Would that be a performance problem (by effectively allowing only a >>>>> single >>>>> item to be sent to the firmware at any given time?) >>>> >>>> >>>> >>>> The only thing that may suffer here is wmi mgmt tx but I wouldn't >>>> consider that performance critical. >>> >>> >>> >>> In that case, why use credits at all? >> >> >> Excellent question. >> >> Firmware provides 2 HTC tx credits for WMI. I guess this is on >> purpose. I imagine WMI mgmt tx can hang (i.e. not replenish tx >> credits). In that case the remaining tx credit could be used to try >> recovering, e.g. down/stop vdev (I think it should drop all pending tx >> and thus free the stuck HTC tx credit). >> >> It might be a good idea to keep this recovery strategy in mind when >> implementing the "wait for tx replenishment" wmi tx blocking. > > > Seems to me we should just fix the firmware to respond quickly..and if we > know exactly which > command is not being answered (quickly) in the firmware, it might be easier > to debug > it. > > That said, while debugging I think I have seen cases where one message would > be consumed for a long time, and then suddenly it frees up again. > > So, I'm not sure what to do. Maybe could improve firmware to return an id > so we know exactly which of the messages was processed, and then the driver > could do the work of figuring out what commands are outstanding by just > keeping > a copy in RAM.... > I suspect mgmt_tx frames (for AP FW we send them using WMI) without ACK couse this problem (disassoc + deauth probably). Question if we saw this problem with 636 firmware? In 636 we send mgmt frames using HTT, so we don't consume WMI credits. I will try to reproduce this tommorow. BR Janusz -- 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
