On Fri, 2008-05-23 at 16:26 +0200, Johan Adolfsson wrote: > > -----Original Message----- > > From: libertas-dev-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:libertas-dev-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf > > Of Holger Schurig > > Sent: den 23 maj 2008 16:04 > > To: libertas-dev@xxxxxxxxxxxxxxxxxxx; Dan Williams; > > linux-wireless@xxxxxxxxxxxxxxx; John W. Linville > > Subject: [PATCH] libertas: before sleeping, check for a command result > > > > > > If we don't check for a command response early, but rather sleep, > > then we might sleep despite an already-received command response. > > This will lead to a command-timeout. > > > > Signed-off-by: Holger Schurig <hs4233@xxxxxxxxxxxxxxxxxxxx> > > > > Index: wireless-testing/drivers/net/wireless/libertas/main.c > > =================================================================== > > --- > > wireless-testing.orig/drivers/net/wireless/libertas/main.c > > 2008-05-23 14:25:16.000000000 +0200 > > +++ wireless-testing/drivers/net/wireless/libertas/main.c > > 2008-05-23 14:25:51.000000000 +0200 > > @@ -722,14 +722,14 @@ static int lbs_thread(void *data) > > shouldsleep = 1; /* Something is > > en route to the device already */ > > else if (priv->tx_pending_len > 0) > > shouldsleep = 0; /* We've a > > packet to send */ > > + else if (priv->resp_len[priv->resp_idx]) > > + shouldsleep = 0; /* We have a > > command response */ > > else if (priv->cur_cmd) > > shouldsleep = 1; /* Can't send a > > command; one already running */ > > else if (!list_empty(&priv->cmdpendingq)) > > shouldsleep = 0; /* We have a > > command to send */ > > else if (__kfifo_len(priv->event_fifo)) > > shouldsleep = 0; /* We have an > > event to process */ > > > Hi, > I have experience a couple of timeout and resends and after > sending another commands I get the response from the previous one, > and the patch seems to solve a couple of those for me - > still se some problem fetching packet from firmware with ret = -22 though. > And it could be dependant on how much debug I have turned on.. > > But, shouldn't the above priv->event_fifo check move before > cur_cmd as well? Most likely, yes... > I have no clue what kind of events we are talking about here and > if those can be processed independent of if a cmd is running or not, > just trigged on the comment. Anything that might be handled in lbs_process_event(). Link loss, MIC failure, etc. Dan > Best regards > /Johan > > -- 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
