From: Pedro Estrela (pedro.estrela_at_inesc.pt)
Date: 2002-10-16 13:32:25 UTC
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 managementpacket. 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 == 901Oct 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 ...