More mysterious Tx excessive retries

[Jim Carter]

The ongoing saga of the Dell TrueMobile 1150 (Lucent-Agere firmware 6.16)
vs Linksys WPC11 (Intersil firmware v1.03).

Using the replacement card from Dell, I did tests between driver
versions 0.07, 0.08a, 0.09a, 0.10, 0.11 (skipping 0.07 on the Linksys
card; total of 20 tests).  Behavior was essentially identical in all but
one case; uploads (Dell to Linksys) went at 116 Kby/sec, equivalent to
1 Mb/s, where 5 Mb/s is expected, since 802.11b can't use the full
bandwidth.  When the sending driver (Dell card) was capable of
recognizing "Tx excessive retries", it reported an error on every
packet.  The receiving driver reported occasional errors but under 1%.
All packets were received at least once.  I think they were received 2
or 3 times but duplicates were suppressed at the 4th protocol layer.
In this set of tests both cards reported that they were connected at
11 Mb/s, every time, persisting through reboots of both machines.

However, I had just one test (with 0.08a on Linksys, 0.10 on Dell) that
went at 5 Mb/s and had no reported errors even though the sending driver
could have reported them if there had been any.  This condition could not
be repeated.

When the rate is set to 11M fixed on the Dell card, data is transferred at
1 Mb/s, while 11M auto gives you 0.2 Mb/s.  The rate setting on the Linksys
card has no effect.  This was tested with version 0.10 on both cards but
I'm pretty sure the same thing happens with any driver versions.  WEP off,
or 40 bits, or 104 bits, gives the same result.  In this set of tests the
Dell card reported 2 Mb/s while Linksys reported 11 Mb/s.  The previous
behavior, where the Dell card reports 11 Mb/s, could not be brought back,
despite rebooting both machines several times (see below for the reason).

Previously, but not this time, a second Linksys card was tried and data
rates were the same. Previously using WinXP to a Cisco-Aironet access
point, data was uploaded at apparently saturation rates using either card,
and using the Dell card in Linux, but the Linksys card under Linux could
associate with the AP but could not send packets.

I have no idea what's going on or what to try next.

The only nasty behavior noticed on driver 0.11 was that when you do
"rmmod orinoco_cs" it gets a seg fault.  Clearly the new alloc_orinocodev
(or actually its inverse) has to be involved, but I couldn't see what might
cause it in the source code.  Here's the barfage from the syslog:

hermes.c: 5 Apr 2002 David Gibson <hermes at gibson.dropbear.id.au>
orinoco.c 0.11 (David Gibson <hermes at gibson.dropbear.id.au> and others)
orinoco_cs.c 0.11 (David Gibson <hermes at gibson.dropbear.id.au> and others)
eth1: Station identity 001f:0001:0006:0010
eth1: Looks like a Lucent/Agere firmware version 6.16
eth1: Ad-hoc demo mode supported
eth1: IEEE standard IBSS ad-hoc mode supported
eth1: WEP supported, 104-bit key
eth1: MAC address 00:02:2D:5A:50:A9
eth1: Station name "HERMES I"
eth1: ready
eth1: index 0x01: Vcc 3.3, irq 11, io 0x0100-0x013f

invalid operand: 0000
CPU:    0
EIP:    0010:[kmem_extra_free_checks+62/100]    Not tainted
EFLAGS: 00010002
eax: cf05b400   ebx: cf05b000   ecx: 00000400   edx: cffe15f0
esi: cf05b72c   edi: cff30b24   ebp: 0000072c   esp: cf7e9f00
ds: 0018   es: 0018   ss: 0018
Process rmmod (pid: 2249, stackpage=cf7e9000)
Stack: cff30b24 cf05b72c cf05b72c cffe15f0 00000001 c012843d cffe15f0 cff30b24
       cf05b72c cf05b72c d189227c cf05b540 cf7e9f70 cf7e9f70 00000400 cf05b72c
       00000282 d18914b3 cf05b72c cf17a694 cf05b770 c01caf03 d1891000 fffffff0
Call Trace: [kfree+333/456] [<d189227c>] [orinoco_cs:__insmod_orinoco_cs_S.text_L3600+1107/3616] [__generic_copy_to_user+51/72] [orinoco_cs:__insmod_orinoco_cs_S.rodata_L416+78/416]
   [free_module+23/152] [sys_delete_module+243/432] [system_call+51/56]

Code: 0f 0b 8b 47 14 83 f8 ff 74 11 3b 44 24 10 75 02 0f 0b 8b 44

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc at math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)