management frames are lost during high load situations

[Pedro Estrela]

Hello HostAP,

I'm having the following problem, which was NOT solved by using the latest
1.4.9 firmware.

Simply put, when the card is put in stress with a major downstream UDP flow
(greater than a flood ping), the AP is unable to process further
associations/reassociations. In this scenario, a station moving from one
unloaded AP to a loaded AP will keep on sending associations until the load
stops. (card details: NIC: id=0x8002 v1.0.1 , PRI: id=0x15 v0.3.0,  STA:
id=0x1f v0.8.0).


To try to solve this situation, i've tryed to insert an artificial busy loop
on prism2_send_mgmt when the queue is full, to try to artificially wait
until the interrupt appears that executes  wake_queue() in IRQ context.
However, my simple patch did not work as expected (see below both the patch
and the resulting log).
Previouly, i was using a old (April) version of the driver with the maximum
number of packets pending for transmition capped to a low value, by
controlling TX and TX_EV events, and calling wake_queues/stop_queues.
However, this solution incresases greatly the CPU usage, and also degrades
maximum 802.11 throughtpt.

Any ideas on this particular problem?



MODIFICATION:
at the end of
static void prism2_send_mgmt(struct net_device *dev,
                             int type, int subtype, char *body,
                             int body_len, int txevent, u8 *addr)

...

#define MAX_BUSY_WAIT 1000
        {
                int count = 0;

                if (in_interrupt())
                        printk("ERROR: send_management IN INTERUPT \n" );

                if (netif_queue_stopped(dev)){
                        printk("netif_queue_stopped while sending management
packet. will probably be lost. \n" );

                        count = 0;
                        while( (count < MAX_BUSY_WAIT) &&
(netif_queue_stopped(dev))){
                                count++;
                                udelay(100);

                                if((count % 100) == 1)
                                        printk("waiting... count == %d \n",
count );
                        }

                        if (!netif_queue_stopped(dev))
                                printk("netif_queue was waked \n" );
                        if (count >= MAX_BUSY_WAIT)
                                printk("TIMEOUT! %d \n", count );
                }
        }

        /* FIX: is it OK to call dev_queue_xmit() here? This can be called
...


RESULT:
Oct 16 03:22:49 estrela kernel: netif_queue_stopped while sending
management packet. will probably be  lost.
Oct 16 03:22:49 estrela kernel: waiting... count == 1
Oct 16 03:22:49 estrela kernel: waiting... count == 101
Oct 16 03:22:49 estrela kernel: waiting... count == 201
Oct 16 03:22:49 estrela kernel: waiting... count == 301
Oct 16 03:22:49 estrela kernel: waiting... count == 401
Oct 16 03:22:49 estrela kernel: waiting... count == 501
Oct 16 03:22:49 estrela kernel: waiting... count == 601
Oct 16 03:22:49 estrela kernel: waiting... count == 701
Oct 16 03:22:49 estrela kernel: waiting... count == 801
Oct 16 03:22:49 estrela kernel: waiting... count == 901
Oct 16 03:22:49 estrela kernel: TIMEOUT! 1000
Oct 16 03:22:49 estrela kernel: wlan0: 00:02:2d:02:2c:dc auth (alg=0
trans#=1 stat=0 len=6fc=00b0) == > 0 (authenticated)
... repeat until load is stopped ...