While stress testing the newest version of the open-source firmware
for BCM43XX devices with the latest pull of wireless-testing, I ran
into a problem of DMA TX queue overrun. Initially I thought this was
due to the firmware change; however, I got the same error with the
standard firmware. I have not seen this before, but it may not be a
regression as it seems to occur only under special circumstances.
The critical code is in b43_dma_tx(), which is called by the .tx
callback routine registered with mac80211.
After the fragment is transmitted by a call to dma_tx_fragment() at
line 1353, the routine checks to see if there are sufficient free
slots (2) to transmit another fragment using the code below:
if ((free_slots(ring) < TX_SLOTS_PER_FRAME) ||
should_inject_overflow(ring)) {
/* This TX ring is full. */
ieee80211_stop_queue(dev->wl->hw,
skb_get_queue_mapping(skb));
ring->stopped = 1;
if (b43_debug(dev, B43_DBG_DMAVERBOSE)) {
b43dbg(dev->wl, "Stopped TX ring %d\n",
ring->index);
}
}
The problem shows up at line 1340 for the next fragment:
B43_WARN_ON(ring->stopped);
if (unlikely(free_slots(ring) < TX_SLOTS_PER_FRAME)) {
b43warn(dev->wl, "DMA queue overflow\n");
err = -ENOSPC;
goto out_unlock;
}
The system generates the warning for ring->stopped and prints the "DMA
queue overflow" message.
My understanding is that mac80211 serializes the calls for each TX
queue, and that the TX callback should not have been entered for this
case.
If I am not understanding the way that mac80211 works, please correct
me. I would also appreciate any suggestions for further debugging.
Larry
--
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
