Re: ipw2100: race between isr_indicate_associated and rx path

Am Donnerstag, 22. Januar 2009 schrieb Zhu Yi:
> On Thu, 2009-01-22 at 00:34 +0800, Helmut Schaa wrote:
> > 1) The firmware receives the assoc response and moves internally to
> > associated
> > state, followed by an interrupt which informs the driver about that
> > change.
> > 2) The driver does _not_ update its internal state to ASSOCIATED in
> > the
> > interrupt handler. Instead it queues a work to be executed later.
> > 3) The firmware receives the identity request from the AP and accepts
> > the
> > frame as it is in associated state. Followed by an interrupt to the
> > driver.
> > 4) The driver gets the rx interrupt but drops the frame due to not
> > being in
> > associated state.
> > 5) The queued work is executed and state changes to associated but the
> > AP will
> > not resend the EAP frame as the firmware already acked it.
> > 
> > Afterwards wpa_supplicant times out because it did not receive
> > anything from the AP.
> 
> Good audit. Can you try if scheduling the work immediately (instead of
> delayed HZ/10) will fix the problem?

Hmm, just wondering if this might break other things. The following comment
seems to indicate why the work is delayed.

1921   /*
1922    * TBD: BSSID is usually 00:00:00:00:00:00 here and not
1923    *      an actual MAC of the AP. Seems like FW sets this
1924    *      address too late. Read it later and expose through
1925    *      /proc or schedule a later task to query and update
1926    */

I guess the work is delayed to work around a firmware issue. However, I'll
try if queuing the work undelayed fixes my issue and does not cause a 
regression in regard to BSSID reading.

Helmut

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword