On 03/26/2013 10:33 AM, Adrian Chadd wrote:
Right. Well, when you reset the FIFO chances are you should walk said FIFO queue in the TXQ (not the pending frames, the "hw" frames) and requeue each to the hardware. What I am doing in my EDMA restart routine in FreeBSD: * (assume TX is stopped, chip is reset, the completed frames are already removed from the FIFO queue in the TXQ); * save the old FIFO count * blank the FIFO count * walk the FIFO list (NOT the pending list), pushing head pointers back into the FIFO - and this will bump the FIFO counter by one each time; * when I've finished that, compare the FIFO count to the old FIFO count - they should match. I've not looked at the ath9k code in too much depth lately as I've been more interested in getting FreeBSD's EDMA code finished (and I think it is, woo!); so if you give me an hour or two I'll go do another code review and see what pops up.
Ok, I'm happy to test patches. Last we tried, we could reproduce the problem very often using lots of stations (32, I think) sending 64kbps or so UDP traffic through an attenuator as we ramp up the attenuation in 10db steps... Thanks, 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
