Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #581 (new defect)

Opened 12 years ago

Last modified 9 years ago

hiccups in ad-hoc mode - connection works again for a while after performing iwlist scan

Reported by: onelektra@gmx.net Assigned to:
Priority: major Milestone:
Component: madwifi: other Version:
Keywords: ad-hoc mode Cc:
Patch is attached: 0 Pending:

Description (Last modified by mrenzmann)

When using madwifi-ng from April 22th and 27th 2006 the link ceases to work after a while. Cell-ID, channel and so on looks all fine in iwconfig output (apart from the fact that the bit rate is always reported as 0 kbit/s). When I perform 'iwlist scan' the link starts working again for a while. I 'm using the driver successfully now with a script that calls 'iwlist ath0 scan' every 10 seconds...

Kernel is vanilla 2.6.16.9 on 32bit Intel, card is cardbus reported as wifi0: mac 5.9 phy 4.3 radio 3.6, Atheros 5212: mem=0xd2000000, irq=11

dmesg often reports:

ath_mgtstart: discard, no xmit buf

followed by an occasional:

tx tasklet restart the queue

Change History

05/02/06 10:50:59 changed by mrenzmann

  • description changed.

05/30/06 18:10:13 changed by nbd@openwrt.org

It seems like the card stops generating interrupts with the HAL_INT_TX status flag. Because of that, ath_tx_tasklet is not being called anymore and thus the transmit queue fills up. Regularly checking the last tx interrupt time (e.g. in the interrupt function) and doing a hardware reset if the delay is too long works around this problem, but it's not a clean solution. No idea where this problem comes from...

10/26/06 06:58:55 changed by mrenzmann

Ron Dippold started a thread in madwifi-devel about this ticket, describing a "workaround solution". #717 reports the same issue, by the way.

12/14/06 23:27:53 changed by proski

It happens for me in the following configuration. MadWifi is acting as an AP and the station is a Windows XP laptop Toshiba Tecra with an Intel PCIe ipw3945 card configured to use 802.11b protocol only.

The problem doesn't happen if Linux is used on the laptop or when 802.11a is used.

The best way to trigger the problem is to use flood ping and adaptive ping consequtively with long packets (10000 bytes). For best effect, the ping should be interrupted an restarted when delays become longer. It takes a few minutes to trigger the problem.

Adding some debug information to ath_tx_draintxq() shows that unreclaimed buffers are in the WME_AC_BE queue. 198 of 200 buffers were there at the time when the driver ran out of buffers.

I have a better workaround. uapsd should be turned off on the AP:

iwpriv ath0 uapds 0

This prevents buffer wasting. Only one or two buffers are claimed for the queues after heavy pings no matter what I try.

05/13/07 15:30:11 changed by nbd@openwrt.org

That workaround is definitely not enough. It may help if you see the same message due to actual queue overflows, but with this issue the problem is not related to high load at all. The card completely stops transmitting at some point for no obvious reason.

(follow-up: ↓ 7 ) 12/11/07 03:55:44 changed by spam@silicium.mine.nu

This issue still persists.
I'm using ath_pci: 0.9.4.5 (0.9.3.3) on a vanilla kernel 2.6.23.9.

Some times it takes days before it shows up, or as now, hours.
I've tried everything mentioned on forums and in bugreports, nothing solved that issue for me:
iwpriv ath0 uapsd 0
iwpriv ath0 bintval 1000
vm.min_free_kbytes = 10000

Is there nothing what can be done about this ?

(in reply to: ↑ 6 ; follow-up: ↓ 8 ) 12/27/07 17:30:28 changed by anonymous

This problem seems to have been resolved (incidentally?). I have no problems with kamikaze r2978. However, with the last kamikaze trunk (r9963 - which use madwifi-dfs) I get again the "ath_mgtstart: discard, no xmit buf" message and the transmission stops working. I've tried to diffs the working and not working version without success. Could someone figure out what is changed?

(in reply to: ↑ 7 ) 12/28/07 10:57:51 changed by anonymous

Replying to anonymous:

This problem seems to have been resolved (incidentally?). I have no problems with kamikaze r2978. However, with the last kamikaze trunk (r9963 - which use madwifi-dfs) I get again the "ath_mgtstart: discard, no xmit buf" message and the transmission stops working. I've tried to diffs the working and not working version without success. Could someone figure out what is changed?

sorry I've made a mess.
I have no problem with madwifi-ng r2978 that cames with openWRT kamikaze r9624. The issue shows up again in madwifi-dfs r3053 that cames with openWRT kamikaze r9963.

05/05/08 17:46:53 changed by julius@zgod.cjb.net

Same problem here. It seems proski's story is also what's happening here (Windows XP with ipw3945). Did anyone try the fix proposed by Ron Dippold?

05/28/08 01:34:42 changed by michal@sawicz.net

I have the same problem with a Nokia N800 as a client, both when the AP (tried on debian stable with madwifi stock, latest and trunk). Are there any known solutions to that problem?