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 <johannes.berg@xxxxxxxxx> > > > > 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: stable@xxxxxxxxxxxxxxx > > Reported-by: Ben Cahill <ben.m.cahill@xxxxxxxxx> > > Signed-off-by: Johannes Berg <johannes.berg@xxxxxxxxx> > > Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@xxxxxxxxx> > > --- > > 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 linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
