> > 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 -- 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
