From: Jouni Malinen (jkmaline_at_cc.hut.fi)
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