On Thu, Apr 17, 2014 at 04:33:58PM -0700, Bing Zhao wrote: > Hi John, > > > Hi Bing, > > > > Assuming the timeout happened due to a firmware bug. Does the > > firmware able to recover after setting adapter->cmd_sent = false > > and the firmware could accept a new commands without locking?. > > 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. > 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. -- James Cameron http://quozl.linux.org.au/ -- 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
