Re: ipw2100: race between isr_indicate_associated and rx path

Am Donnerstag, 22. Januar 2009 schrieb Helmut Schaa:
> 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.

Ok, I've just tried that suggestion but my objection was indeed eligible.
The initial issue was fixed by queuing the work without delay but in some
cases (maybe 1 out of 10) the firmware was not able to provide the BSSID
fast enough (or the host CPU is too fast ;) ). Hence, the driver signals
association with AP 00:0...0:00 to the user space.

Helmut

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