New hardware, old problem: stuck beacon when here is WiFi traffic

[Lev Serebryakov]

Hello, Adrian.
You wrote 30 апреля 2013 г., 19:41:12:

>>   Warm-up:  120  seconds  of  TCP, throughput osculate between 50 and
>>   100Mbit/, several BAR resets, no hangs.
AC> Ok. But did it negotiate A-MPDU?
  I'm not sure. Both ends showed typical N speeds (Windows in
  connection  properties, FreeBSD in "list sta").

AC> It's fine. We'll worry about aggregation later.
  Yep.

AC> So here we go:
AC> Apr 30 12:21:26 gateway kernel: ath0: ath_stoptxdma: tx queue [9]
AC> 0xd8c3000, link 0
AC> Apr 30 12:21:26 gateway kernel: ath0: ath_tx_stopdma: tx queue [0] 0,
AC> active=0, hwpending=0, flags 0x00000000, link 0
AC> Apr 30 12:21:26 gateway kernel: ath0: ath_tx_stopdma: tx queue [1]
AC> 0xc720ed00, active=0, hwpending=0, flags 0x00000000, link 0
AC> Apr 30 12:21:26 gateway kernel: ath0: ath_tx_stopdma: tx queue [2] 0,
AC> active=0, hwpending=0, flags 0x00000000, link 0
AC> Apr 30 12:21:26 gateway kernel: ath0: ath_tx_stopdma: tx queue [3]
AC> 0xd8bec00, active=0, hwpending=0, flags 0x00000000, link 0
AC> Apr 30 12:21:26 gateway kernel: ath0: ath_tx_stopdma: tx queue [8]
AC> 0xc720d2c0, active=0, hwpending=0, flags 0x00000000, link 0

AC> Notice how the hardware queue isn't active at all. There's frames in
AC> the TXQ and the hardware points to the next frame to transmit (but you
AC> didn't provide the whole list of frames that were in the TXQ, so I'm
AC> going on what it said before.)
 I've provided everything I've had in log :)

-- 
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>