On Thu, 2010-02-04 at 08:28 +0100, Holger Schurig wrote: > > > 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. There should be some reset logic in there for each bus type; it was only ever hooked up for USB because it's easy to do a USB reset. SDIO and SPI are somewhat harder because often it's board-specific thing. Not sure what to do there; we did try writing various SDIO registers that were supposed to reset the card but that never worked. Dan -- 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
