Re: [PATCH] libertas: cfg80211 support

[Holger Schurig <holgerschurig@gmail.com>]

> > I had an application running that was pinging and showed the
> > signal level. Then I moved out-of-reach of the AP.
> > This happened:
> 
> The command timeout code is just screwed all around.  We've
> already seen that some commands just take longer than we're
> expecting them to.  I think we should just get rid of the
> command retry stuff completely and return EBUSY when trying to
> submit additional commands if the firmware hasn't replied yet.

I think the same.

I think in my case --- which I haven't debugged completely 
yet  --- user-space code was going wild. The firmware command 
001f (get RSSI) failed. Which is to be expected, because the 
firmware noticed that there's no longer a connection to an AP.

However, user-space nl80211 code seems to have been buggy and 
issued the same command in a loop. This flooded the the 
command-execution logic in libertas, and it couldn't cope with 
it.

AFAIK the error I had had nothing to do with the cfg80211-code 
inside the libertas driver. Or maybe it is, I'll write a little 
program that floods libertas via cfg80211 with commands in a 
tight loop, let's see what happens. :-)


Getting rid of the command-retry and returning an error instead 
seems to be a sane thing.

> I don't think I've *ever* seen recovery from this situation
> unless the firmware finally sends the command reply back, which
> has happened in some cases with SD8686.  IMHO the command retry
> stuff causes more problems than it's worth, given that it never
> actually fixes anything or recovers from the timeout.
> 
> If the firmware is hung, the only way to get the device back is
> to power-cycle it or possibly do a USB reset.  Retrying a
> command just doesn't work.

In my case, I could do a "pccardctl eject" / "pccardctl insert" 
sequence :-)   Not nice. Maybe we need a signal from 
core-libertas to the libertas-drivers, so that they decide what 
to do.

-- 
http://www.holgerschurig.de