Este driver sigue trayendo cola y demostrando su estado de inmadurez.
Existe un bug en la forma de gestionar la cola de transmisión de datos de ath9k, que causa que las conexiones se queden bloqueadas cuando hay transmisión intensiva de datos, especialmente cuando se trabaja en modo 802.11n
Los afectados por este bug, en dmesg podrán observar estos errores:
ath: Chip reset failed
> ath: Failed to stop TX DMA in 100 msec after killing last frame
> ath: Failed to stop TX DMA in 100 msec after killing last frame
> ath: Failed to stop TX DMA in 100 msec after killing last frame
> ath: Failed to stop TX DMA in 100 msec after killing last frame
> ath: Failed to stop TX DMA in 100 msec after killing last frame
> ath: Failed to stop TX DMA in 100 msec after killing last frameAdemás de que sus conexiones se bloquearán constantemente.
Este bug, sumado a otra "
race condition" en el subsistema de gestión del cifrado WEP/WPA utilizando el hardware de los adaptadores, el cual ya comenté anteriormente
en otro hilo de este foro, hacen de este driver uno de los más problemáticos para usar en conexiones normales (en modo managed) en linux.
Este segundo bug en la cola TX, además, podría afectar tambien al adaptador cuando trabaja en modo monitor inyectando paquetes.
Ya existe un pequeño parche para resolver este bug, si bien los kernels estándar actuales de la serie vanilla aun podrían presentar estos errores*.
* El kernel custom 2.6.38 en el que estoy trabajando para próximas distros tendrá el driver ath9k parcheado a tal efecto :-) 
