On 06/19/2012 08:15 PM, Jonathan Nieder wrote: > Hi again, > > Jonathan Nieder wrote: > >> As discussed at [1], Camaleón has been experiencing unwanted random >> wireless reconnects with various 3.2.y kernels up to and including >> 3.2.19: > > This was first reproduced on a kernel closely based on 3.2.9. It > would typically happen pretty reliably once a day or so. Four days of > testing a kernel close to 3.2.2 haven't triggered it again[1]. > > The only brcm80211 change in that range is > > f96b08a7e6f6 brcmsmac: fix tx queue flush infinite loop > The WARN_ONCE added by the commit above still triggers sometimes. Two recent commits I did regarding this are in 3.4-stable. Not sure if they have been ported to 3.2 as well. 85091fc brcm80211: smac: fix endless retry of A-MPDU transmissions badc4f0 brcm80211: smac: resume transmit fifo upon receiving frames However, I still observe the warning so I am looking what other event trigger this issue. > So maybe the timeout is too short and this safety is tripping when it > shouldn't. I've asked Camaleón to try a recent 3.2.y kernel with and > without that commit reverted to test this guess. > > That leaves another mystery: which of the 22 changes listed at [2] was > providing relief in earlier tests? E.g., does > >> c261bdf8acad brcm80211: smac: indicate severe problems to Mac80211 > > make it easier to recover from this kind of error? Are there commands > we should run or diagnostics to try to get a better sense of what is > going on? Not commends yet. We want to add debugfs support. The commit above only notifies mac80211 that we have a problem. However, the recovery scenario that mac80211 initiates upon this notification turns out to be killing for brcmsmac. Gr. AvS -- 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
