On Sun, Sep 28, 2008 at 6:38 AM, Derek Smithies <email@example.com>
do an iwlist ath0 scan
- does this clear the queue?
- other iwlist/iwconfig type commands might fix it..
iwconfig ath0 txpower old_setting_for_power
could fix it - this does a complete reset of the hal. It does not
reset the slot time, but it is worth trying..
using iwconfig to set the power is less invasive than the scan option.
Please report back if either of these commands help.
On Sun, 28 Sep 2008, ming li wrote:
We are experiencing a problem in the madwifi driver, which makes it unable
send any packets out of the interface. We are using an Atheros XXX card, in
Ah-demo mode. And our packets belong to the Background Tos and Voice Tos.
We observe that under heavy load, or long (or flaky) links the outgoing
(as seen by tc -s qdisc) would be full and packets would be going out.
On twiddling with athdebug, we found that in the function
the ath_tx_processq was not being called (probably because txqactive()
What's more baffling is that this problem most of the time only affects
being sent through the non best effort queue. That is, packets sent on say
background queue (tos 0x8) are not sent out of the interface, and tc -s
shows them as dropped. Whereas packets sent on the best effort queue (Tos of
go without any problem -- and the debug mesasge at the start of
We have tried various workarounds -- like a) disabling the timing out of
entries from ic->ic_sta, b) repeatedly sending background pings via
the best effort and background queues to 'force' pkts out and
ath_tx_tasklet_q0123 being called. c) Increasing the priority of ksoftirqd
threads to enable the queue to be drained quickly Etc.
All these approaches fail leaving us with the only option of destroying and
recreating the interface, which ofcourse clears up the queue.
For some reason, this happens more often over either bad links or when the
sender sees a heavy network load -- like when multiple transfers are taking
place in its vicinity.
We are using madwifi 0.9.3.2 version in 802.11b (11 Mbps), Adhoc-demo mode
setting Wmm parameters. The kernel version is 2.6.21. The wifi0 has a
pfifo_fast queue, whereas ath0 queing disabled. This is being tested on a
Mac mini with an 802.11b/g Atheros card:
/* lspci output */
02:00.0 Ethernet controller: Atheros Communications, Inc. Unknown
device 001c (rev 01)
Subsystem: Apple Computer Inc. Unknown device 0086
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at 90100000 (64-bit, non-prefetchable) [size=64K]
Capabilities:  Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities:  Message Signalled Interrupts: Mask- 64bit-
Address: 00000000 Data: 0000
Capabilities:  Express Legacy Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <512ns, L1 <64us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0
Link: Latency L0s <512ns, L1 <64us
Link: ASPM Disabled RCB 128 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities:  MSI-X: Enable- Mask- TabSize=1
Vector table: BAR=0 offset=00000000
PBA: BAR=0 offset=00000000
Capabilities:  Advanced Error Reporting
Capabilities:  Virtual Channel
Has anyone seen something like this ?. What workaround could we try ?
Under what condition will txqactive() returns false? It calls
ah_getTxIntrQueue() in hal which
is close source.
PS: i. We have verified that the same problem happens with a 0.9.4 madwifi
ii. Please feel free to ask for additional information.
iii. The associated madwifi ticket is given at
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485