Michael Buesch wrote: > b43 allocates a bouncebuffer, if the supplied TX skb is in an invalid > memory range for DMA. > However, this is broken in that it fails to copy over some metadata to the > new skb. > > This patch fixes three problems: > * Failure to adjust the ieee80211_tx_info pointer to the new buffer. > This results in a kmemcheck warning. > * Failure to copy the skb cb, which contains ieee80211_tx_info, to the new skb. > This results in breakage of various TX-status postprocessing (Rate control). > * Failure to transfer the queue mapping. > This results in the wrong queue being stopped on saturation and can result in queue overflow. > > Signed-off-by: Michael Buesch <mb@xxxxxxxxx> > Tested-by: Christian Casteyde <casteyde.christian@xxxxxxx> > > --- > > Thanks to Johannes for tracking down this hard to find bug and > thanks to Christian for testing. > > Larry, I think I remember you reported a strange rate control failure on > one of your cards. Does this patch fix it? > > b43legacy: > Note that b43legacy has the same bug and also needs fixing. > Is there a maintainer for b43legacy? Michael, There was not really a rate-control problem - just a difficulty with the operator. I was making a transmit test, then interrogating the rate from the same console. By that time, the rate was back to 1 Mb/s for control messages. When I looped the transmit tests, and looked at the rate in a separate console, the code was doing mostly what it should. Mostly because the success rate for the LP PHY does not satisfy the assumptions that mistrel makes. One gets a higher throughput with a fixed rate, but that will improve as power control is implemented. There is no maintainer for b43legacy. I have ported your patch for b43 to legacy and I will be testing and submitting it. 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
