On Sat, Apr 19, 2014 at 10:34:10AM +1000, James Cameron wrote: > On Fri, Apr 18, 2014 at 12:16:07PM -0700, Bing Zhao wrote: > > 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. > > Thanks. I neglected to mention the time period; beacons and probe > responses are seen for many minutes after the timeout report by the > driver, and I have not yet tested for how long this lasts. The > probe responses are in reply to new probe requests. It makes me > think the card is working fine, apart from not communicating with > the host. Downgrading wireless firmware to 14.66.9.p80 has fixed this problem. -- 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
