"Charles M. Hannum" wrote:

> Many people have observed that wi(4) uses a lot of CPU time.  I have 
> identified this as being primarily due to busy-waiting for TX commands to 
> complete.  The attached hack is a first step at eliminating that problem, and 
> improves wi(4) performance substantially on my test machines.
> 
> If other people could test this and let me know the results, that would be 
> helpful -- especially with Orinoco cards, since I don't have any(*).
> 
> Note that this hack is not finished.  It currently causes a race condition 
> between wi_cmd() (primarily ifconfig(8) and wiconfig(8)) and the transmit 
> path that can cause spurious errors.  It's intended as a test to see if the 
> methodology works well enough to bother finishing.

On my Toshiba-badged Orinoco:

	wi0 at pcmcia1 function 0: <TOSHIBA, Wireless LAN Card, Version 01.01>
	wi0: 802.11 address 00:02:2d:52:d6:f8
	wi0: using Lucent Technologies, WaveLAN/IEEE
	wi0: Lucent Firmware: Station (8.42.1)
	wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps

I see the following errors in groups of three:

	wi0: bad alloc 1f7 != 1f9, cur 2 nxt 2
	wi0: bad alloc 1f8 != 1f9, cur 2 nxt 2
	wi0: bad alloc 1f9 != 1f7, cur 0 nxt 0

	wi0: bad alloc 1f7 != 1f9, cur 2 nxt 2
	wi0: bad alloc 1f8 != 1f9, cur 2 nxt 2
	wi0: bad alloc 1f9 != 1f7, cur 0 nxt 0

	wi0: bad alloc 1f7 != 1f8, cur 1 nxt 1
	wi0: bad alloc 1f8 != 1f7, cur 0 nxt 0
	wi0: bad alloc 1f9 != 1f7, cur 0 nxt 0

	wi0: bad alloc 1f7 != 1f9, cur 2 nxt 2
	wi0: bad alloc 1f8 != 1f9, cur 2 nxt 2
	wi0: bad alloc 1f9 != 1f7, cur 0 nxt 0

After each group of three messages there is no more network traffic
and an "ifconfig down/ifconfig up" gets it working for a little while
longer.  The longest it worked was for maybe 3 minutes with an ssh to
another local box just doing "ls" and other simple commands.  Would
these be the "spurious errors" you refer to?

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/