Re: Prism2 Host AP - new release 2002-04-05

From: Jouni Malinen (
Date: 2002-04-07 17:30:07 UTC

On Sun, Apr 07, 2002 at 07:01:21PM +0200, Bjørn Mork wrote:

> This made me optimistic since I've had a small performance problem
> with the latest releases (losing packets when transmitting many of
> them, causing TX speed to drop and reducing TX performance to a
> fraction of the theoretical). I'm using the driver on a 66 MHz 486
> with a Vadem ISA-PCMCIA controller, so interrupt latency is probably
> as high as it can get.

If that was enough to make you optimistic, lets see, what 2002-04-07 release does with the optimized TX path.. ;-)

I might need to get myself a test platform with a bit less performance to notice this kind of problems. I happen to have a 25 MHz 386DX somewhere, but that might be pushing it a bit too much ;-) Hmm.. I think I also have a 486 laptop somewhere, but it support only 5V cards. Anyway, this might be good use for it..

> Apr 7 18:46:01 canardo kernel: wlan0: TXEXC - fid=0x051f - status=0x0008 ([FormErr]) tx_control=000e

Hmm.. I don't remember seeing FormErr with any released driver version (it is easy to get them by trying to send invalid frames, but maybe there's something else happening in this case).

> I guess the problem is that the platform is too slow handling the
> packets, not really that they are lost in the air. Probably not much
> that can be done about that. Your changelog made me a bit optimistic,
> but I couldn't really notice any improvement. The TX performance is
> still terrible (~500 kbits/s as opposed to the RX speed of ~5 Mbits/s).

What about 2002-04-07 release with PRISM2_USE_CMD_COMPL_INTERRUPT defined?

> And the 2002-04-05 version seems to cause another problem I'm having
> on this platform more often (I've seen this on all releases so far,
> but rarely on the 2002-x-x versions so far): Something causes the
> driver to try resetting the card, but the reset fails. When this
> happens I have to do a "ifconfig wlan0 down; cardctl eject; cardctl
> insert" to make things work again. Just toggling the interface down
> and up is not sufficient.

I have been unable to get this happening in my tests.. The reset code seems to have working fine, but probably there is something that I have been able to duplicate. Does 'iwpriv wlan0 reset 0' or 'iwpriv wlan0 reset 1' reset the card correctly? At least 1 (i.e., COR sreset) should be enough.

> Here are the logs from a couple of such errors using the 2002-04-05
> release:

> Apr 6 21:09:31 canardo kernel: Already released txfid found at idx 1

Yet another thing I haven't seen for ages.. You sure have a good debugging environment for detecting problems ;-)

I'll have to take a closer look at this and try to somehow duplicate the problems so that I could find the real reason for them.

> I'm not entirely sure whether it's the driver or the PCMCIA subsystem
> that really causes the failure, but my life would have been a lot
> easier if the driver could somehow detect it and do a successful
> reset instead of the endless failing one.

At least the transmit command usage on TX path was completely sub-optimal till the todays release (and even with it, unless optional test version is enabled). And yes, the resetting code is certainly supposed to fix any problem.

Jouni Malinen                                            PGP id EFC895FA

This archive was generated by hypermail 2.1.4.