Hi James, > > That "adapter->cmd_sent = false" was hoping the firmware is still > > alive and can respond to a new command. The reality is that the > > timeout usually indicates the firmware has already hung. Sending > > another command won't recover it in this case. > > I'm dealing with a firmware hang when more than 13 nodes are in an ad-hoc > IBSS, and I've just found out isn't entirely a firmware hang; in that we can see > beacons and probe responses from the card, using tcpdump and monitor > mode. > > I'm interested to know if the "firmware hangs" that you experiment with > prevent autonomous RF TX, or if RF TX typically proceeds. It depends. Even if firmware hangs the hardware is still alive. So you could see beacons and probe responses from the card if hardware has been programmed before firmware hangs. > > I guess you are using SDIO chip. If your host controller supports > > MMC_POWER_OFF/UP, you can reset the chip with this approach: > > > > mmc_remove_host(host); > > /* some delay */ > > mmc_add_host(host); > > Thanks, adding that to my list of things to try, as I am using SDIO too. This code (with 20ms delay) is already in latest driver. Your platform and controller may require a longer delay. Regards, Bing -- 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
