On 01/06/2011 10:51 PM, Vasanthakumar Thiagarajan wrote:
On Fri, Jan 07, 2011 at 06:16:04AM +0530, greearb@xxxxxxxxxxxxxxx wrote:From: Ben Greear<greearb@xxxxxxxxxxxxxxx> We should not get to this state, but we do. What is worse, many times the xmit logic still will not start, probably due to tids being paused when they shouldn't be. Signed-off-by: Ben Greear<greearb@xxxxxxxxxxxxxxx> --- NOTE: This needs review. It might be too much of a hack for upstream code, and at best it works around a small part of the problem. :100644 100644 3aae523... 547fb44... M drivers/net/wireless/ath/ath9k/xmit.c drivers/net/wireless/ath/ath9k/xmit.c | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c index 3aae523..547fb44 100644 --- a/drivers/net/wireless/ath/ath9k/xmit.c +++ b/drivers/net/wireless/ath/ath9k/xmit.c @@ -2110,6 +2110,27 @@ static void ath_tx_complete_poll_work(struct work_struct *work) } else { txq->axq_tx_inprogress = true; } + } else { + /* If the queue has pending buffers, then it + * should be doing tx work (and have axq_depth). + * Shouldn't get to this state I think..but + * perhaps we do. + */ + if (!list_empty(&txq->axq_acq)) { + ath_err(ath9k_hw_common(sc->sc_ah), + "txq: %p axq_qnum: %i," + " axq_link: %p" + " pending frames: %i" + " axq_acq is not empty, but" + " axq_depth is zero. Calling" + " ath_txq_schedule to restart" + " tx logic.\n", + txq, txq->axq_qnum, + txq->axq_link, + txq->pending_frames); + ATH_DBG_WARN_ON_ONCE(1); + ath_txq_schedule(sc, txq);NAK. This complete work monitors the hw q periodically and does a reset if a hang is detected. This work is no way meant to schedule aggr. This change really does not make any sense. Scheduling a tid periodically would introduce reordering issues especially when there are more retries.
Ok, but if the system is in the state where it hits this code branch, it seems that no new packets are sent to the chip to be transmitted. I see this, for instance, in debugfs (with my debugfs patches applied): axq-qnum: 2 3 1 0 axq-depth: 0 0 0 0 axq-ampdu_depth: 0 0 0 0 axq-stopped 1 0 0 0 tx-in-progress 0 0 0 0 pending-frames 70 0 0 0 txq_headidx: 0 0 0 0 txq_tailidx: 0 0 0 0 axq_q empty: 0 1 1 0 axq_acq empty: 0 1 1 1 txq_fifo_pending: 1 1 1 1 The queue is stopped, axq_acq and axq_q are not empty, there are pending frames, and no axq-depth. I cannot figure out why the queue is stopped since it seems it should be running when axq-depth is zero. Thanks for the review, I'll back this hack out of my testing tree. 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
