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

From: Bjørn Mork (
Date: 2002-04-09 13:41:45 UTC

Jouni Malinen <> writes:
> 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.. ;-)

Jumped at it as soon as I had a chance :-)

>> 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).

Really? I am getting quite a few of these.. Since February 2002 using only 2002-x-x versions:

canardo:~$ grep FormErr /var/log/debug |wc -l   58501

Is this a symptom or a cause of my other problems?

>> 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?

Didn't make any noticeable difference. The load isn't very high in any case.

>> 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.

Will test that the next time this happens.

>> 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 ;-)

Oh, I'm the best when it comes to creating problems :-)

>> 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.

It's not much of a problem if this happens only to me. I only have a few hundred kbits/s uplink anyway, and I can always hack some script to do the cardctl eject/insert automatically on failure. I can live with that. I am just curiuos where the p


This archive was generated by hypermail 2.1.4.