The current powersave code in the ath(4) driver / HAL is causing issues on the AR9331. Even if powersave is disabled, the chip is put into powersave mode when no VAPs are in use. This seems to lock up the DMA side of things. Symptoms: * lots of "disable rx dma failed" messages * no packets being transmitted/received * TX/RX interrupt counts don't increase * if AH_INTERRUPT_DEBUGGING is defined, then sync interrupts are posted - 0x200 and 0x40. Now, I'm not sure yet what those bits are. I guess it's similar to the AR9340 ones - AR9340_INTR_SYNC_MAC_SLEEP_ACCESS (0x40). That meant that it was configured whilst the MAC was asleep. Ugh. If i disable the power save code in if_ath.c (ie, make all the ath_hal_setpowermode() calls to HAL_PM_AWAKE) then things work fine. So, figure out what is being programmed whilst the MAC is asleep, or what is currently not shut down correctly before the MAC is put to sleep.
Specifically: root@freebsd-carambola2:/home/adrian # sysctl dev.ath.0.stats.sync_intr | grep -v ': 0$' dev.ath.0.stats.sync_intr.10: 52 dev.ath.0.stats.sync_intr.13: 52 The bits from ar9300reg.h: AR9300_INTR_SYNC_RADM_CPL_TLP_ABORT = 0x00000400, AR9300_INTR_SYNC_LOCAL_TIMEOUT = 0x00002000, .. now, the former is not entirely right - those bits are PCIe host interface specific. The latter bit is likely valid for the AR9331. I'll have to get a hold of the AR9331 host interface description from Atheros to figure out what the sync interrupt bits actually mean here. I do think that a register was programmed whilst the NIC was in network or full sleep. I'll have to figure out why my debugging code isn't picking up on that.
This has been fixed in r269748. Well, "fixed" - it just cold resets the NIC as appropriately rather than trying to figure out why it's failing.