[Prism54-devel] Re: islpci_mgt_transaction and stability

[Luis R. Rodriguez]

On Sun, Aug 08, 2004 at 11:32:09PM +0300, Denis Vlasenko wrote:
> Hi Luis, folks,
> 
> I am doing some stability testing. I instrumented
> driver to report each mgt transaction:
> 
> int
> islpci_mgt_transaction(struct net_device *ndev,
>                        int operation, unsigned long oid,
>                        void *senddata, int sendlen,
>                        struct islpci_mgmtframe **recvframe)
> {
> ...
>         printk(KERN_DEBUG "islpci_mgt_transaction(op %d, oid %08x, sendlen %d)\n",
>                 operation, oid, sendlen
>         );
> 
> I have two prism54 in STA<->AP setup and I positioned them so that link is bad
> and they frequently lose assoc. Which is easy to do, hardware is rather crappy
> RF-wise ;). Then, I fired UDP flood in both directions.
> 
> Typical throughput numbers can be found below the sig.
> 
> But I noticed one interesting thing. Whenever link is restored,
> I see lone "islpci_mgt_transaction(op 0, oid 10000001, sendlen 6)"
> in syslog. What that can be?
> 
> oid_mgt.c:
>         OID_STRUCT_C(DOT11_OID_BSSID, 0x10000001, u8[6], OID_TYPE_RAW),
> 
> I wonder, is this the result of (re)assoc happened?
> Or maybe it is other way around and this transaction kicked hw so
> that hw noticed the problem and reassociated?

Hmm, strange indeed. My only guess would be a bogus call to
mgt_get_request where the "extra" parameter was set to some value it
shouldn't have. When extra is set, the oid used for the get can be
affected by:

oid = isl_oid[n].oid + extra;

Perhaps try printk'ing extra here for all gets see if that triggered it
(?) That's the only thing I can think of.

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E