Re: [Madwifi-users] Interrupt problems in 11g-only master mode (AR5212).

[Sam L. <sa...@er...>]

On Tuesday 10 August 2004 09:48 am, DOm wrote:
> Hallo,
>
> i start this new thread to try to discover what causes the problem.
> Many of us have some instability and get system unresponsive when using
> madwifi in 11g-only master mode. Someone suggested to investigate using
> a system profile, but i'm not very used to these tools.
> Anyway, i tried to use oprofile (http://oprofile.sf.net) to see what
> causes the interrupt storm (at least _i_ think it is an interrupt
> problem).
>
> I use my pci card in master mode, but i have not a bridge setup, i route
> packet on the wired lan using:
> 	sysctl -w net.ipv4.ip_forward=1
>
> I turned on debug messages of dev.ath.debug to print interrupt
> information with:
> 	sysctl -w dev.ath.debug=0x000000001000
>
> under normal operation (ping or no manual action) the debug output is:
> 	ath_intr: status 0x10000
> 	ath_intr: status 0x40

0x10000 is the SWBA interrupt (look in hal/ah.h for the interrupt bit 
assignments).  You get one of these every time a beacon needs to be prepared 
for transmission.

>
> repeatedly, but when the system become slow, that is when i try to
> use the full bandwidth (for example using wget on the client), i get
> this output:
> 	ath_intr: status 0x10000
> 	ath_beacon_tasklet: beacon queue 9 did not stop?

This means sending the beacon frame failed for some reason.  Once this happens 
you're hosed as the other transmit queues backup behind the beacon queue 
(which is highest priority).  You need to figure out why the beacon frame 
transmit failed.   Commonly this happens because the transmit descriptor got 
corrupted so the DMA failed (e.g. the dma length is mismatched to the beacon 
frame contents).

>
> sometime happen that the system do not become slow but stop trasmitting
> packets and output such a message:
> 	ath_hardstart: discard, no xmit buf

Yes, as described above once the beacon queue blocks the lower priority tx 
queues stop.

>
> I'm not able to understand where the problem is from the system profiler
> output, so i send you a file with a filtered output (only kernel and
> ath* stuff). If it is not enough, please give me more instruction on how
> to proceed.
>
> In the second attached file there is a summary of my system, to help you
> to know my machine. I made a script to generate such file and to add a
> bit of provacy (masking mac addresses and ipv6 addresses, and wep keys),
> if you are interested in such a dummy script i can post it, maybe it can
> be useful for other bug reports.
>
> I hope you can guess where is the problem.

You need to figure out what happened to the beacon transmit.  Looking at the 
contents of the beacon tx descriptor would be a good place to start.  You 
might also verify this descriptor didn't somehow get reused for transmitting 
a data frame.

	Sam