David Gnedt <david.gnedt@xxxxxxxxxxx> writes: > The queue stopping/waking functionality was broken in a way that could > cause the TX to stall if the right circumstances are met. > > The problem was caused by tx_work, which is scheduled on each TX operation. > If the firmware buffer is full, tx_work does nothing. In combinition with > stopped queues or non-continues transfers, tx_work is never scheduled again. > Moreover the low watermark introduced by > 9df86e2e702c6d5547aced7f241addd2d698bb11 never takes effect because of some > old code. > > Solve this by scheduling tx_work every time tx_queue is non-empty and > firmware buffer is freed on tx_complete. > > This also solves a possible but unlikely case: If less frames than the high > watermark are queued, but more than firmware buffer can hold. This results > in queues staying awake but the only scheduled tx_work doesn't transfer all > frames, so the remaining frames are stuck in the queue until more frames > get queued and tx_work is scheduled again. This looks good. Unfortunately I wasn't able to test it yet, but if it solves your issue I think it's best to get it in now. Thanks for fixing this. > Signed-off-by: David Gnedt <david.gnedt@xxxxxxxxxxx> Acked-by: Kalle Valo <kvalo@xxxxxxxxxx> -- Kalle Valo -- 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
