[Prism54-devel] handle mgmt timeouts by resetting hardware
Luis R. Rodriguez
mcgrof at ruslug.rutgers.edu
Wed Aug 4 01:04:39 UTC 2004
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
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
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
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.
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.
> Prism54-devel mailing list
> Prism54-devel at prism54.org
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://prism54.org/pipermail/prism54-devel/attachments/20040803/e0ddf462/attachment-0001.pgp
More information about the Prism54-devel