WiFi Slowdown on CF

[Dave Kroetsch]

Wow..

This is on CF8385 module and we've got a nasty bug.  We think we've 
isolated root cause.  It seems to be interrupt servicing in the 
if_cs_interrupt routine is too slow, and the driver falls behind the 
module.  The problem we see is specifically on the RX processing which 
calls:

	lbs_process_rxed_packet(priv, skb);

This takes too long sometimes, depending on what else is going in the IP 
layer and then the driver misses interrupts/packets from the module. 
This causes the module to go into some recovery state where 
interrupts/packets seem to only come through every 150ms which explains 
the slowness we're seeing.

We're able to broadcast data to the device under test and watch the 
interrupts fire and get serviced - ONLY incoming UDP traffic is used 
during this test.  Simply making the following change:

	if (cause & IF_CS_BIT_RX)
         {
		struct sk_buff *skb;
		lbs_deb_cs("rx packet\n");

		skb = if_cs_receive_data(priv);

		if (skb)
                 {
-                   lbs_process_rxed_packet(priv, skb);
+		    kfree_skb(skb);
                 }
	}

throws away the data, BUT the module keeps up and none of the udp_mirror 
testing (posted to the group earlier) will break it. We can tell because 
we watch the physical interrupt lines from hardware.

One thought is to move the libs_process_rxed_packet into a tasklet for 
later processing and put the skb in a buffer.  Perhaps others don't see 
this problem because of faster machines, but we're on an embedded 400MHz 
arm, so this is a big issue for us.

Any suggestions?

Thanks,
	Dave