On Mon, 2012-03-05 at 14:46 -0500, John W. Linville wrote:
> On Sun, Mar 04, 2012 at 08:50:46AM -0800, Wey-Yi Guy wrote:
> > From: Johannes Berg <[email protected]>
> > 
> > If we only monitor while associated, the following
> > can happen:
> >  - we're associated, and the queue stuck check
> >    runs, setting the queue "touch" time to X
> >  - we disassociate, stopping the monitoring,
> >    which leaves the time set to X
> >  - almost 2s later, we associate, and enqueue
> >    a frame
> >  - before the frame is transmitted, we monitor
> >    for stuck queues, and find the time set to
> >    X, although it is now later than X + 2000ms,
> >    so we decide that the queue is stuck and
> >    erroneously restart the device
> > 
> > It happens more with P2P because there we can
> > go between associated/unassociated frequently.
> > 
> > Cc: [email protected]
> > Reported-by: Ben Cahill <[email protected]>
> > Signed-off-by: Johannes Berg <[email protected]>
> > Signed-off-by: Wey-Yi Guy <[email protected]>
> > ---
> 
> So what is the effect of this bug?  An unnecessary firmware restart?  How 
> often does this happen?

Oh, guess I forgot that. The effect is essentially that the firmware
restarts unnecessarily, which causes strange things to happen.

> It is very late in the 3.3 cycle.  Fixes should be for regressions, crashes, 
> etc.

Since unfortunately P2P isn't really stable yet and before P2P hardly
anyone saw this I suppose it doesn't matter all that much ...

johannes

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to