From: Bjørn Mork (bjorn_at_mork.no)
Date: 2002-04-09 13:41:45 UTC
Jouni Malinen <jkmaline_at_cc.hut.fi> 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
Bjørn