[Prism54-devel] handle mgmt timeouts by resetting hardware

[Luis R. Rodriguez]

Denis,

this was a lot of work you did but I am not sure yet if the principal
cause to mgt timeouts are due to locking screwups. I'll have to check
myself how it possible that a recursive call is being made here, but
last I checked the main problem was due to us not doing things the
firmware likes, i.e.: remove the oid that causes a timeout on the commit
list and the timeout is gone. This leads me to believe we just have to
figure out a correct way to commit oids.

I know in MLME_MANUAL mode you first set the MLME mode, then mode. Then
set all you want (except essid I think), and to finalize you set
mode again.

I also know setting essid "unlatches" the setting of all oids. By this I
mean that setting some oids don't necessarily "commit" until some event
occurs -- that is, they're "latched". Setting essid is one way to
unlatch them all.

Also, since I've been working with WPA client support I've noticed that
timeouts are more frequent in extended mode. Because of this I've been
forced to dive into mlme_transaction lock hell and review it. So far it
seems it all magically should work. Also, because of what I state above
regarding the "unlatching" of the oids, I'm looking into an alternative
method of "commiting" by just setting essid instead of going through the 
whole commit_list's.

And as for positive feedback for the patch:

1. IMO we should accept this patch only if we're certain that the cause of
the timeouts is a recursive call and not a firmware bug.

2. This patch should be re-done since, should it be accepted, we have to 
send it to netdev and policy is to split patches up into separate concrete 
pieces of work. i.e: 

	patch 1: printk changes
	patch 2: space changes
	patch 3: remove NULL setting
	patch 4: timer work
	etc

I realize this is a pain in the ass. It is, but it's kernel policy.

3. I don't think many people will like to add printk's for successful
cases in routines unless we're debugging. Again, a good way to do this
is to completely move away from our current debugging mechanism to 
netif_msg, as stated in our TODO list.

	Luis

On Tue, Aug 03, 2004 at 10:42:54PM +0300, Denis Vlasenko wrote:
> On Tuesday 03 August 2004 20:14, Margit Schubert-While wrote:
> > Denis scribeth :
> >  > I am resubmiting corrected patch against today's CVS.
> >  > Run tested. Please apply.
> >
> > Nope, The iw_handler tables seem to be screwed up.
> 
> Oh my. Yes. They are...
> 
> +#define        PRISM54_SET_OID_STR     SIOCIWFIRSTPRIV+22
> +#define        PRISM54_SET_OID_ADDR    SIOCIWFIRSTPRIV+24
>  
>  #define PRISM54_GET_PRISMHDR   SIOCIWFIRSTPRIV+23
>  #define PRISM54_SET_PRISMHDR   SIOCIWFIRSTPRIV+24
> 
> Fixed. Attached.
> --
> vda


> _______________________________________________
> Prism54-devel mailing list
> Prism54-devel at prism54.org
> http://prism54.org/mailman/listinfo/prism54-devel


-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://prism54.org/pipermail/prism54-devel/attachments/20040803/e0ddf462/attachment-0001.pgp